6. Nachrichtenabstraktion (Message Abstraction)

Jede Hauptversion von HTTP definiert ihre eigene Syntax zur Kommunikation von Nachrichten. Dieser Abschnitt definiert einen abstrakten Datentyp für HTTP-Nachrichten basierend auf einer Verallgemeinerung dieser Nachrichtenmerkmale, gemeinsamen Struktur und Fähigkeit zur Übermittlung von Semantik. Diese Abstraktion wird verwendet, um Anforderungen an Sender und Empfänger zu definieren, die unabhängig von der HTTP-Version sind, sodass eine Nachricht in einer Version über andere Versionen weitergeleitet werden kann, ohne ihre Bedeutung zu ändern.

Eine "Nachricht" (message) besteht aus folgenden Elementen:

• Kontrolldaten zur Beschreibung und Weiterleitung der Nachricht,

• einer Header-Nachschlagetabelle von Name/Wert-Paaren zur Erweiterung dieser Kontrolldaten und zur Übermittlung zusätzlicher Informationen über den Sender, die Nachricht, den Inhalt oder den Kontext,

• einem potenziell unbegrenzten Inhaltsstrom und

• einer Trailer-Nachschlagetabelle von Name/Wert-Paaren zur Kommunikation von Informationen, die beim Senden des Inhalts erhalten wurden.

Framing und Kontrolldaten werden zuerst gesendet, gefolgt von einem Header-Abschnitt, der Felder für die Header-Tabelle enthält. Wenn eine Nachricht Inhalt enthält, wird der Inhalt nach dem Header-Abschnitt gesendet, möglicherweise gefolgt von einem Trailer-Abschnitt, der Felder für die Trailer-Tabelle enthalten kann.

Nachrichten sollen als Stream verarbeitet werden, wobei der Zweck dieses Streams und seine fortgesetzte Verarbeitung während des Lesens offenbart wird. Daher beschreiben Kontrolldaten, was der Empfänger sofort wissen muss, Header-Felder beschreiben, was vor dem Empfang des Inhalts bekannt sein muss, der Inhalt (falls vorhanden) enthält vermutlich, was der Empfänger zur Erfüllung der Nachrichtensemantik benötigt oder möchte, und Trailer-Felder liefern optionale Metadaten, die vor dem Senden des Inhalts unbekannt waren.

Nachrichten sollen "selbstbeschreibend" (self-descriptive) sein: Alles, was ein Empfänger über die Nachricht wissen muss, kann durch Betrachtung der Nachricht selbst bestimmt werden, nach der Dekodierung oder Wiederherstellung von Teilen, die während der Übertragung komprimiert oder ausgelassen wurden, ohne ein Verständnis des aktuellen Anwendungszustands des Senders (durch vorherige Nachrichten etabliert) zu erfordern. Ein Client MUSS jedoch bei der Analyse, Interpretation oder Zwischenspeicherung einer entsprechenden Antwort Kenntnisse über die Anfrage behalten. Beispielsweise sehen Antworten auf die HEAD-Methode genauso aus wie der Anfang einer Antwort auf GET, können aber nicht auf die gleiche Weise analysiert werden.

Beachten Sie, dass diese Nachrichtenabstraktion eine Verallgemeinerung über viele Versionen von HTTP ist, einschließlich Funktionen, die in einigen Versionen möglicherweise nicht vorhanden sind. Beispielsweise wurden Trailer innerhalb der HTTP/1.1-Chunked-Transfer-Codierung als Trailer-Abschnitt nach dem Inhalt eingeführt. Eine äquivalente Funktion ist in HTTP/2 und HTTP/3 innerhalb des Header-Blocks vorhanden, der jeden Stream beendet.

6.1. Framing und Vollständigkeit (Framing and Completeness)

Nachrichten-Framing (Message framing) gibt an, wie jede Nachricht beginnt und endet, sodass jede Nachricht von anderen Nachrichten oder Rauschen auf derselben Verbindung unterschieden werden kann. Jede Hauptversion von HTTP definiert ihren eigenen Framing-Mechanismus.

HTTP/0.9 und frühe Bereitstellungen von HTTP/1.0 verwendeten das Schließen der zugrunde liegenden Verbindung, um eine Antwort zu beenden. Aus Gründen der Abwärtskompatibilität ist dieses implizite Framing auch in HTTP/1.1 erlaubt. Implizites Framing kann jedoch keine unvollständige Antwort unterscheiden, wenn die Verbindung vorzeitig geschlossen wird. Aus diesem Grund verwenden fast alle modernen Implementierungen explizites Framing in Form von längendelimitierten Sequenzen von Nachrichtendaten.

Eine Nachricht wird als "vollständig" (complete) betrachtet, wenn alle durch ihr Framing angegebenen Oktette verfügbar sind. Beachten Sie, dass eine Antwortnachricht, die durch das Schließen der zugrunde liegenden Verbindung beendet wird, wenn kein explizites Framing verwendet wird, als vollständig betrachtet wird, auch wenn sie von einer unvollständigen Antwort möglicherweise nicht zu unterscheiden ist, es sei denn, ein Fehler auf Transportebene zeigt an, dass sie nicht vollständig ist.

6.2. Kontrolldaten (Control Data)

Nachrichten beginnen mit Kontrolldaten, die ihren Hauptzweck beschreiben. Anfragenachrichten-Kontrolldaten umfassen eine Anfragemethode (request method) (Abschnitt 9), ein Anfrageziel (request target) (Abschnitt 7.1) und eine Protokollversion (protocol version) (Abschnitt 2.5). Antwortnachrichten-Kontrolldaten umfassen einen Statuscode (status code) (Abschnitt 15), einen optionalen Reason-Phrase und eine Protokollversion.

In HTTP/1.1 ([HTTP/1.1]) und früher werden Kontrolldaten als erste Zeile einer Nachricht gesendet. In HTTP/2 ([HTTP/2]) und HTTP/3 ([HTTP/3]) werden Kontrolldaten als Pseudo-Header-Felder mit einem reservierten Namenspräfix (z. B. ":authority") gesendet.

Jede HTTP-Nachricht hat eine Protokollversion. Abhängig von der verwendeten Version kann sie innerhalb der Nachricht explizit identifiziert oder durch die Verbindung abgeleitet werden, über die die Nachricht empfangen wird. Empfänger verwenden diese Versionsinformationen, um Einschränkungen oder Potenziale für die spätere Kommunikation mit diesem Sender zu bestimmen.

Wenn eine Nachricht von einem Intermediär weitergeleitet wird, wird die Protokollversion aktualisiert, um die von diesem Intermediär verwendete Version widerzuspiegeln. Das Via-Header-Feld (Abschnitt 7.6.3) wird verwendet, um Upstream-Protokollinformationen innerhalb einer weitergeleiteten Nachricht zu kommunizieren.

Ein Client SOLLTE eine Anfrageversion senden, die der höchsten Version entspricht, der der Client entspricht und deren Hauptversion nicht höher ist als die höchste vom Server unterstützte Version, falls dies bekannt ist. Ein Client DARF KEINE Version senden, der er nicht entspricht.

Ein Client KANN eine niedrigere Anfrageversion senden, wenn bekannt ist, dass der Server die HTTP-Spezifikation falsch implementiert, aber nur nachdem der Client mindestens eine normale Anfrage versucht und aus dem Antwortstatuscode oder Header-Feldern (z. B. Server) festgestellt hat, dass der Server höhere Anfrageversionen unsachgemäß behandelt.

Ein Server SOLLTE eine Antwortversion senden, die der höchsten Version entspricht, der der Server entspricht und die eine Hauptversion hat, die kleiner oder gleich der in der Anfrage empfangenen Version ist. Ein Server DARF KEINE Version senden, der er nicht entspricht. Ein Server kann eine 505 (HTTP Version Not Supported)-Antwort senden, wenn er aus irgendeinem Grund den Dienst der Hauptprotokollversion des Clients ablehnen möchte.

Ein Empfänger, der eine Nachricht mit einer Hauptversionsnummer empfängt, die er implementiert, und einer Nebenversionsnummer, die höher ist als das, was er implementiert, SOLLTE die Nachricht verarbeiten, als wäre sie in der höchsten Nebenversion innerhalb dieser Hauptversion, der der Empfänger entspricht. Ein Empfänger kann davon ausgehen, dass eine Nachricht mit einer höheren Nebenversion, wenn sie an einen Empfänger gesendet wird, der noch keine Unterstützung für diese höhere Version angezeigt hat, ausreichend abwärtskompatibel ist, um von jeder Implementierung derselben Hauptversion sicher verarbeitet zu werden.

6.3. Header-Felder (Header Fields)

Felder (Abschnitt 5), die vor dem Inhalt gesendet oder empfangen werden, werden als "Header-Felder" (header fields) (oder umgangssprachlich einfach "Headers") bezeichnet.

Der "Header-Abschnitt" (header section) einer Nachricht besteht aus einer Sequenz von Header-Feldzeilen. Jedes Header-Feld kann die Nachrichtensemantik modifizieren oder erweitern, den Sender beschreiben, den Inhalt definieren oder zusätzlichen Kontext bereitstellen.

Hinweis: Wir bezeichnen benannte Felder speziell als "Header-Feld", wenn sie nur im Header-Abschnitt gesendet werden dürfen.

6.4. Inhalt (Content)

HTTP-Nachrichten übertragen oft eine vollständige oder teilweise Repräsentation als Nachrichten-"Inhalt" (content): einen Oktett-Stream, der nach dem Header-Abschnitt gesendet wird, wie durch das Nachrichten-Framing abgegrenzt.

Diese abstrakte Definition von Inhalt spiegelt die Daten wider, nachdem sie aus dem Nachrichten-Framing extrahiert wurden. Beispielsweise kann ein HTTP/1.1-Nachrichtenkörper (Abschnitt 6 von [HTTP/1.1]) aus einem mit der Chunked-Transfer-Codierung codierten Datenstrom bestehen -- eine Sequenz von Daten-Chunks, einem Null-Längen-Chunk und einem Trailer-Abschnitt -- während der Inhalt derselben Nachricht nur den Datenstrom nach der Dekodierung der Transfer-Codierung umfasst; er umfasst nicht die Chunk-Längen, die Chunked-Framing-Syntax oder die Trailer-Felder (Abschnitt 6.5).

Hinweis: Einige Feldnamen haben ein "Content-"-Präfix. Dies ist eine informelle Konvention; während sich einige dieser Felder auf den Inhalt der Nachricht beziehen, wie oben definiert, sind andere auf die ausgewählte Repräsentation (Abschnitt 3.2) beschränkt. Siehe die Definition des einzelnen Feldes zur Disambiguierung.

6.4.1. Inhaltssemantik (Content Semantics)

Der Zweck des Inhalts in einer Anfrage wird durch die Methodensemantik (Abschnitt 9) definiert.

Beispielsweise repräsentiert eine Repräsentation im Inhalt einer PUT-Anfrage (Abschnitt 9.3.4) den gewünschten Zustand der Zielressource, nachdem die Anfrage erfolgreich angewendet wurde, während eine Repräsentation im Inhalt einer POST-Anfrage (Abschnitt 9.3.3) Informationen repräsentiert, die von der Zielressource verarbeitet werden sollen.

In einer Antwort wird der Zweck des Inhalts durch die Anfragemethode, den Antwortstatuscode (Abschnitt 15) und Antwortfelder definiert, die diesen Inhalt beschreiben. Beispielsweise repräsentiert der Inhalt einer 200 (OK)-Antwort auf GET (Abschnitt 9.3.1) den aktuellen Zustand der Zielressource, wie zum Zeitpunkt des Nachrichtenentstehungsdatums (Abschnitt 6.6.1) beobachtet, während der Inhalt desselben Statuscodes in einer Antwort auf POST entweder das Verarbeitungsergebnis oder den neuen Zustand der Zielressource nach Anwendung der Verarbeitung repräsentieren kann.

Der Inhalt einer 206 (Partial Content)-Antwort auf GET enthält entweder einen einzelnen Teil der ausgewählten Repräsentation oder einen mehrteiligen Nachrichtenkörper, der mehrere Teile dieser Repräsentation enthält, wie in Abschnitt 15.3.7 beschrieben.

Antwortnachrichten mit einem Fehlerstatuscode enthalten normalerweise Inhalt, der den Fehlerzustand repräsentiert, sodass der Inhalt den Fehlerzustand und welche Schritte zur Behebung vorgeschlagen werden, beschreibt.

Antworten auf die HEAD-Anfragemethode (Abschnitt 9.3.2) enthalten niemals Inhalt; die zugehörigen Antwort-Header-Felder geben nur an, was ihre Werte gewesen wären, wenn die Anfragemethode GET (Abschnitt 9.3.1) gewesen wäre.

2xx (Successful)-Antworten auf eine CONNECT-Anfragemethode (Abschnitt 9.3.6) schalten die Verbindung in den Tunnel-Modus, anstatt Inhalt zu haben.

Alle 1xx (Informational)-, 204 (No Content)- und 304 (Not Modified)-Antworten enthalten keinen Inhalt.

Alle anderen Antworten enthalten Inhalt, obwohl dieser Inhalt von Null-Länge sein kann.

6.4.2. Identifizierung von Inhalt (Identifying Content)

Wenn eine vollständige oder teilweise Repräsentation als Nachrichteninhalt übertragen wird, ist es oft wünschenswert, dass der Sender einen Identifikator für eine Ressource bereitstellt, die dieser spezifischen Repräsentation entspricht, oder dass der Empfänger einen solchen bestimmt. Beispielsweise könnte ein Client, der eine GET-Anfrage für eine Ressource für "den aktuellen Wetterbericht" stellt, einen Identifikator wünschen, der spezifisch für den zurückgegebenen Inhalt ist (z. B. "Wetterbericht für Laguna Beach am 20210720T1711"). Dies kann nützlich sein, um Inhalte von Ressourcen zu teilen oder als Lesezeichen zu setzen, von denen erwartet wird, dass sie sich im Laufe der Zeit ändernde Repräsentationen haben.

Für eine Anfragenachricht:

• Wenn die Anfrage ein Content-Location-Header-Feld hat, dann behauptet der Sender, dass der Inhalt eine Repräsentation der durch den Content-Location-Feldwert identifizierten Ressource ist. Eine solche Behauptung kann jedoch nicht vertraut werden, es sei denn, sie kann durch andere Mittel (nicht durch diese Spezifikation definiert) überprüft werden. Die Informationen können dennoch für Revisionsverlauf-Links nützlich sein.

• Andernfalls wird der Inhalt nicht durch HTTP identifiziert, aber ein spezifischerer Identifikator kann innerhalb des Inhalts selbst bereitgestellt werden.

Für eine Antwortnachricht werden die folgenden Regeln in der Reihenfolge angewendet, bis eine Übereinstimmung gefunden wird:

1. Wenn die Anfragemethode HEAD ist oder der Antwortstatuscode 204 (No Content) oder 304 (Not Modified) ist, gibt es keinen Inhalt in der Antwort.

2. Wenn die Anfragemethode GET ist und der Antwortstatuscode 200 (OK) ist, ist der Inhalt eine Repräsentation der Zielressource (Abschnitt 7.1).

3. Wenn die Anfragemethode GET ist und der Antwortstatuscode 203 (Non-Authoritative Information) ist, ist der Inhalt eine potenziell modifizierte oder erweiterte Repräsentation der Zielressource, wie von einem Intermediär bereitgestellt.

4. Wenn die Anfragemethode GET ist und der Antwortstatuscode 206 (Partial Content) ist, ist der Inhalt ein oder mehrere Teile einer Repräsentation der Zielressource.

5. Wenn die Antwort ein Content-Location-Header-Feld hat und sein Feldwert eine Referenz auf dieselbe URI wie die Ziel-URI ist, ist der Inhalt eine Repräsentation der Zielressource.

6. Wenn die Antwort ein Content-Location-Header-Feld hat und sein Feldwert eine Referenz auf eine URI ist, die sich von der Ziel-URI unterscheidet, dann behauptet der Sender, dass der Inhalt eine Repräsentation der durch den Content-Location-Feldwert identifizierten Ressource ist. Eine solche Behauptung kann jedoch nicht vertraut werden, es sei denn, sie kann durch andere Mittel (nicht durch diese Spezifikation definiert) überprüft werden.

7. Andernfalls wird der Inhalt nicht durch HTTP identifiziert, aber ein spezifischerer Identifikator kann innerhalb des Inhalts selbst bereitgestellt werden.

6.5. Trailer-Felder (Trailer Fields)

Felder (Abschnitt 5), die sich innerhalb eines "Trailer-Abschnitts" (trailer section) befinden, werden als "Trailer-Felder" (trailer fields) (oder umgangssprachlich einfach "Trailers") bezeichnet. Trailer-Felder können nützlich sein, um Nachrichtenintegritätsprüfungen, digitale Signaturen, Liefermetriken oder Nachverarbeitungsstatusinformationen bereitzustellen.

Trailer-Felder sollten separat von den Feldern im Header-Abschnitt verarbeitet und gespeichert werden, um Widersprüche zur Nachrichtensemantik zu vermeiden, die zum Zeitpunkt des Abschlusses des Header-Abschnitts bekannt war. Das Vorhandensein oder Fehlen bestimmter Header-Felder kann Entscheidungen beeinflussen, die für das Routing oder die Verarbeitung der Nachricht als Ganzes getroffen werden, bevor die Trailer empfangen werden; diese Entscheidungen können nicht durch die spätere Entdeckung von Trailer-Feldern rückgängig gemacht werden.

6.5.1. Einschränkungen bei der Verwendung von Trailern (Limitations on Use of Trailers)

Ein Trailer-Abschnitt ist nur möglich, wenn er von der verwendeten HTTP-Version unterstützt und durch einen expliziten Framing-Mechanismus aktiviert wird. Beispielsweise erlaubt die Chunked-Transfer-Codierung in HTTP/1.1, einen Trailer-Abschnitt nach dem Inhalt zu senden (Abschnitt 7.1.2 von [HTTP/1.1]).

Viele Felder können nicht außerhalb des Header-Abschnitts verarbeitet werden, da ihre Auswertung vor dem Empfang des Inhalts erforderlich ist, wie z. B. solche, die Nachrichten-Framing, Routing, Authentifizierung, Anfrage-Modifikatoren, Antwortkontrollen oder Inhaltsformat beschreiben. Ein Sender DARF KEIN Trailer-Feld generieren, es sei denn, der Sender weiß, dass die Definition des entsprechenden Header-Feldnamens erlaubt, dass das Feld in Trailern gesendet wird.

Trailer-Felder können von Intermediären, die Nachrichten von einer Protokollversion zu einer anderen weiterleiten, schwierig zu verarbeiten sein. Wenn die gesamte Nachricht während der Übertragung gepuffert werden kann, könnten einige Intermediäre Trailer-Felder in den Header-Abschnitt (gegebenenfalls) zusammenführen, bevor sie weitergeleitet wird. In den meisten Fällen werden die Trailer jedoch einfach verworfen. Ein Empfänger DARF KEIN Trailer-Feld in einen Header-Abschnitt zusammenführen, es sei denn, der Empfänger versteht die entsprechende Header-Felddefinition und diese Definition erlaubt explizit und definiert, wie Trailer-Feldwerte sicher zusammengeführt werden können.

Das Vorhandensein des Schlüsselworts "trailers" im TE-Header-Feld (Abschnitt 10.1.4) einer Anfrage zeigt an, dass der Client bereit ist, Trailer-Felder zu akzeptieren, für sich selbst und für alle nachgelagerten Clients. Für Anfragen von einem Intermediär bedeutet dies, dass alle nachgelagerten Clients bereit sind, Trailer-Felder in der weitergeleiteten Antwort zu akzeptieren. Beachten Sie, dass das Vorhandensein von "trailers" nicht bedeutet, dass der/die Client(s) irgendein bestimmtes Trailer-Feld in der Antwort verarbeiten wird/werden; nur dass der/die Trailer-Abschnitt(e) nicht von einem der Clients verworfen wird/werden.

Aufgrund des Potenzials, dass Trailer-Felder während der Übertragung verworfen werden, SOLLTE ein Server KEINE Trailer-Felder generieren, von denen er glaubt, dass sie für den Benutzeragenten notwendig sind, um sie zu empfangen.

6.5.2. Verarbeitung von Trailer-Feldern (Processing Trailer Fields)

Das "Trailer"-Header-Feld (Abschnitt 6.6.2) kann gesendet werden, um Felder anzuzeigen, die wahrscheinlich im Trailer-Abschnitt gesendet werden, was es Empfängern ermöglicht, sich auf deren Empfang vorzubereiten, bevor der Inhalt verarbeitet wird. Dies könnte beispielsweise nützlich sein, wenn ein Feldname anzeigt, dass eine dynamische Prüfsumme berechnet werden sollte, während der Inhalt empfangen wird, und dann sofort beim Empfang des Trailer-Feldwerts überprüft werden sollte.

Wie Header-Felder werden Trailer-Felder mit demselben Namen in der Reihenfolge ihres Empfangs verarbeitet; mehrere Trailer-Feldzeilen mit demselben Namen haben die äquivalente Semantik wie das Anfügen der mehreren Werte als Liste von Mitgliedern. Trailer-Felder, die möglicherweise mehr als einmal während einer Nachricht generiert werden, MÜSSEN als listenbasiertes Feld definiert werden, auch wenn jeder Mitgliedswert nur einmal pro empfangener Feldzeile verarbeitet wird.

Am Ende einer Nachricht KANN ein Empfänger die Menge der empfangenen Trailer-Felder als Datenstruktur von Name/Wert-Paaren behandeln, ähnlich (aber getrennt von) den Header-Feldern. Zusätzliche Verarbeitungserwartungen, falls vorhanden, können innerhalb der Feldspezifikation für ein Feld definiert werden, das zur Verwendung in Trailern vorgesehen ist.

6.6. Nachrichten-Metadaten (Message Metadata)

Felder, die die Nachricht selbst beschreiben, wie z. B. wann und wie die Nachricht generiert wurde, können sowohl in Anfragen als auch in Antworten erscheinen.

6.6.1. Date

Das "Date"-Header-Feld repräsentiert das Datum und die Uhrzeit, zu der die Nachricht entstanden ist, mit derselben Semantik wie das Origination Date Field (orig-date), das in Abschnitt 3.6.1 von [RFC5322] definiert ist. Der Feldwert ist ein HTTP-date, wie in Abschnitt 5.6.7 definiert.

Date = HTTP-date

Ein Beispiel ist:

Date: Tue, 15 Nov 1994 08:12:31 GMT

Ein Sender, der ein Date-Header-Feld generiert, SOLLTE seinen Feldwert als die beste verfügbare Annäherung an Datum und Uhrzeit der Nachrichtengenerierung generieren. Theoretisch sollte das Datum den Moment unmittelbar vor der Generierung des Nachrichteninhalts repräsentieren. In der Praxis kann ein Sender den Datumswert zu jedem Zeitpunkt während der Nachrichtenentstehung generieren.

Ein Ursprungsserver mit einer Uhr (wie in Abschnitt 5.6.7 definiert) MUSS ein Date-Header-Feld in allen 2xx (Successful)-, 3xx (Redirection)- und 4xx (Client Error)-Antworten generieren und KANN ein Date-Header-Feld in 1xx (Informational)- und 5xx (Server Error)-Antworten generieren.

Ein Ursprungsserver ohne Uhr DARF KEIN Date-Header-Feld generieren.

Ein Empfänger mit einer Uhr, der eine Antwortnachricht ohne Date-Header-Feld empfängt, MUSS die Zeit aufzeichnen, zu der sie empfangen wurde, und ein entsprechendes Date-Header-Feld zum Header-Abschnitt der Nachricht hinzufügen, wenn sie zwischengespeichert oder nachgelagert weitergeleitet wird.

Ein Empfänger mit einer Uhr, der eine Antwort mit einem ungültigen Date-Header-Feldwert empfängt, KANN diesen Wert durch die Zeit ersetzen, zu der diese Antwort empfangen wurde.

Ein Benutzeragent KANN ein Date-Header-Feld in einer Anfrage senden, wird dies jedoch im Allgemeinen nicht tun, es sei denn, es wird angenommen, dass es nützliche Informationen an den Server übermittelt. Beispielsweise könnten benutzerdefinierte Anwendungen von HTTP ein Date übermitteln, wenn erwartet wird, dass der Server seine Interpretation der Benutzeranfrage basierend auf Unterschieden zwischen den Uhren des Benutzeragenten und des Servers anpasst.

6.6.2. Trailer

Das "Trailer"-Header-Feld liefert eine Liste von Feldnamen, die der Sender voraussichtlich als Trailer-Felder innerhalb dieser Nachricht senden wird. Dies ermöglicht es einem Empfänger, sich auf den Empfang der angegebenen Metadaten vorzubereiten, bevor er mit der Verarbeitung des Inhalts beginnt.

Trailer = #field-name

Beispielsweise könnte ein Sender anzeigen, dass eine Signatur berechnet wird, während der Inhalt gestreamt wird, und die endgültige Signatur als Trailer-Feld bereitstellen. Dies ermöglicht es einem Empfänger, dieselbe Überprüfung im laufenden Betrieb durchzuführen, während er den Inhalt empfängt.

Ein Sender, der beabsichtigt, ein oder mehrere Trailer-Felder in einer Nachricht zu generieren, SOLLTE ein Trailer-Header-Feld im Header-Abschnitt dieser Nachricht generieren, um anzuzeigen, welche Felder in den Trailern vorhanden sein könnten.

Wenn ein Intermediär den Trailer-Abschnitt während der Übertragung verwirft, könnte das Trailer-Feld einen Hinweis darauf geben, welche Metadaten verloren gingen, obwohl es keine Garantie gibt, dass ein Sender von Trailer immer durchzieht, indem er die benannten Felder sendet.