Zum Hauptinhalt springen

4. Übertragungscodierungen

Transferkodierungsnamen werden verwendet, um eine Kodierungstransformation anzuzeigen, die auf einen Payload-Body angewendet wurde, angewendet werden kann oder angewendet werden muss, um einen "sicheren Transport" durch das Netzwerk zu gewährleisten. Dies unterscheidet sich von einer Inhaltskodierung (content coding) darin, dass die Transferkodierung eine Eigenschaft der Nachricht und nicht eine Eigenschaft der übertragenen Repräsentation ist.

transfer-coding    = "chunked" ; Section 4.1
                   / "compress" ; Section 4.2.1
                   / "deflate" ; Section 4.2.2
                   / "gzip" ; Section 4.2.3
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )

Parameter haben die Form eines Namens oder eines name=value-Paares.

transfer-parameter = token BWS "=" BWS ( token / quoted-string )

Alle Namen von Transferkodierungen sind case-insensitiv und sollten im Register für HTTP-Transferkodierungen registriert werden, wie in Abschnitt 8.4 definiert. Sie werden in den Header-Feldern TE (Abschnitt 4.3) und Transfer-Encoding (Abschnitt 3.3.1) verwendet.

4.1. Chunked-Übertragungscodierung​

Die chunked-Transferkodierung umhüllt den Payload-Body, um ihn als eine Reihe von Chunks zu übertragen, von denen jeder seinen eigenen Größenindikator hat, gefolgt von einem OPTIONALEN Trailer, der Header-Felder enthält. Chunked ermöglicht es, Inhaltsströme unbekannter Größe als eine Abfolge längenabgegrenzter Puffer zu übertragen, wodurch der Absender die Verbindungspersistenz erhalten und der Empfänger wissen kann, wann er die gesamte Nachricht empfangen hat.

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF

chunk-data     = 1*OCTET ; a sequence of chunk-size octets

Das Feld chunk-size ist eine Zeichenkette aus Hexadezimalziffern, die die Größe der chunk-data in Oktetten angibt. Die chunked-Transferkodierung ist abgeschlossen, wenn ein Chunk mit einer chunk-size von null empfangen wird, möglicherweise gefolgt von einem Trailer und schließlich durch eine Leerzeile beendet.

Ein Empfänger muss in der Lage sein, die chunked-Transferkodierung zu parsen und zu dekodieren.

4.1.1. Chunk-Erweiterungen​

Die chunked-Kodierung erlaubt es jedem Chunk, null oder mehr Chunk-Erweiterungen einzuschließen, unmittelbar nach der chunk-size, um Metadaten pro Chunk (etwa eine Signatur oder einen Hash), Steuerinformationen mitten in der Nachricht oder eine Randomisierung der Nachrichtenkörpergröße bereitzustellen.

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )

chunk-ext-name = token
chunk-ext-val  = token / quoted-string

Die chunked-Kodierung ist spezifisch für jede Verbindung und wird wahrscheinlich von jedem Empfänger (einschließlich Vermittlern) entfernt oder neu kodiert, bevor eine höhere Anwendung Gelegenheit hat, die Erweiterungen zu prüfen. Daher ist die Verwendung von Chunk-Erweiterungen im Allgemeinen auf spezialisierte HTTP-Dienste wie "Long Polling" (bei dem Client und Server gemeinsame Erwartungen bezüglich der Verwendung von Chunk-Erweiterungen haben können) oder zum Auffüllen innerhalb einer Ende-zu-Ende-gesicherten Verbindung beschränkt.

Ein Empfänger muss nicht erkannte Chunk-Erweiterungen ignorieren. Ein Server sollte die Gesamtlänge der in einer Anfrage empfangenen Chunk-Erweiterungen auf ein für die bereitgestellten Dienste angemessenes Maß begrenzen, so wie er Längenbeschränkungen und Zeitüberschreitungen auf andere Teile einer Nachricht anwendet, und eine geeignete 4xx-Antwort (Client Error) erzeugen, wenn dieses Maß überschritten wird.

4.1.2. Chunked-Trailer-Teil​

Ein Trailer erlaubt es dem Absender, am Ende einer gechunkten Nachricht zusätzliche Felder einzuschließen, um Metadaten bereitzustellen, die während des Sendens des Nachrichtenkörpers dynamisch erzeugt werden könnten, etwa eine Nachrichtenintegritätsprüfung, eine digitale Signatur oder einen Nachbearbeitungsstatus. Die Trailer-Felder sind mit Header-Feldern identisch, mit der Ausnahme, dass sie in einem Chunked-Trailer statt im Header-Abschnitt der Nachricht gesendet werden.

trailer-part   = *( header-field CRLF )

Ein Absender darf KEINEN Trailer erzeugen, der ein Feld enthält, das für das Nachrichten-Framing (z. B. Transfer-Encoding und Content-Length), das Routing (z. B. Host), Anforderungsmodifizierer (z. B. Steuerungen und Bedingungen in Abschnitt 5 von [RFC7231]), Authentifizierung (z. B. siehe [RFC7235] und [RFC6265]), Antwortsteuerdaten (z. B. siehe Abschnitt 7.1 von [RFC7231]) oder die Bestimmung, wie der Payload zu verarbeiten ist (z. B. Content-Encoding, Content-Type, Content-Range und Trailer), notwendig ist.

Wenn eine gechunkte Nachricht mit einem nicht leeren Trailer empfangen wird, KANN der Empfänger die Felder (abgesehen von den oben verbotenen) so verarbeiten, als wären sie an den Header-Abschnitt der Nachricht angehängt worden. Ein Empfänger muss alle Felder ignorieren (oder als Fehler betrachten), die in einem Trailer nicht gesendet werden dürfen, da ihre Verarbeitung, als wären sie im Header-Abschnitt vorhanden, externe Sicherheitsfilter umgehen könnte.

Sofern die Anfrage nicht ein Header-Feld TE enthält, das "trailers" als akzeptabel anzeigt, wie in Abschnitt 4.3 beschrieben, SOLLTE ein Server keine Trailer-Felder erzeugen, von denen er glaubt, dass sie für den Empfang durch den User Agent notwendig sind. Ohne ein TE mit "trailers" sollte der Server annehmen, dass die Trailer-Felder auf dem Weg zum User Agent möglicherweise stillschweigend verworfen werden. Diese Anforderung erlaubt es Vermittlern, eine de-chunkte Nachricht an einen HTTP/1.0-Empfänger weiterzuleiten, ohne die gesamte Antwort zu puffern.

4.1.3. Dekodieren von Chunked​

Ein Prozess zum Dekodieren der chunked-Transferkodierung kann in Pseudocode wie folgt dargestellt werden:

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
   read chunk-data and CRLF
   append chunk-data to decoded-body
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer field is allowed to be sent in a trailer) {
       append trailer field to existing header fields
   }
   read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
Remove Trailer from existing header fields

4.2. Kompressionskodierungen​

Die unten definierten Kodierungen können verwendet werden, um den Payload einer Nachricht zu komprimieren.

4.2.1. Compress-Kodierung​

Die "compress"-Kodierung ist eine adaptive Lempel-Ziv-Welch-Kodierung (LZW) [Welch], die häufig vom UNIX-Dateikomprimierungsprogramm "compress" erzeugt wird. Ein Empfänger SOLLTE "x-compress" als gleichwertig zu "compress" betrachten.

4.2.2. Deflate-Kodierung​

Die "deflate"-Kodierung ist ein "zlib"-Datenformat [RFC1950], das einen "deflate"-komprimierten Datenstrom [RFC1951] enthält, der eine Kombination aus dem Lempel-Ziv-Kompressionsalgorithmus (LZ77) und der Huffman-Kodierung verwendet.

Hinweis: Einige nicht konforme Implementierungen senden die "deflate"-komprimierten Daten ohne den zlib-Wrapper.

4.2.3. Gzip-Kodierung​

Die "gzip"-Kodierung ist eine LZ77-Kodierung mit einer 32-Bit-zyklischen Redundanzprüfung (CRC), die häufig vom gzip-Dateikomprimierungsprogramm [RFC1952] erzeugt wird. Ein Empfänger SOLLTE "x-gzip" als gleichwertig zu "gzip" betrachten.

4.3. TE​

Das Header-Feld "TE" in einer Anfrage zeigt an, welche Transferkodierungen außer chunked der Client in der Antwort zu akzeptieren bereit ist und ob der Client bereit ist, Trailer-Felder in einer chunked-Transferkodierung zu akzeptieren.

Der Feldwert von TE besteht aus einer durch Kommas getrennten Liste von Namen von Transferkodierungen, von denen jede optionale Parameter zulässt (wie in Abschnitt 4 beschrieben), und/oder dem Schlüsselwort "trailers". Ein Client darf den Namen der chunked-Transferkodierung NICHT in TE senden; chunked ist für HTTP/1.1-Empfänger immer akzeptabel.

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
           / ( "1" [ "." 0*3("0") ] )

Drei Beispiele für die Verwendung von TE sind unten aufgeführt.

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Das Vorhandensein des Schlüsselworts "trailers" zeigt an, dass der Client bereit ist, Trailer-Felder in einer chunked-Transferkodierung, wie in Abschnitt 4.1.2 definiert, für sich selbst und jeden nachgelagerten Client zu akzeptieren. Bei Anfragen von einem Vermittler impliziert dies entweder: (a) alle nachgelagerten Clients sind bereit, Trailer-Felder in der weitergeleiteten Antwort zu akzeptieren; oder (b) der Vermittler wird versuchen, die Antwort für die nachgelagerten Empfänger zu puffern. Beachten Sie, dass HTTP/1.1 keine Mittel definiert, um die Größe einer gechunkten Antwort zu begrenzen, sodass ein Vermittler der Pufferung der gesamten Antwort sicher sein könnte.

Wenn mehrere Transferkodierungen akzeptabel sind, KANN der Client die Kodierungen mithilfe eines case-insensitiven "q"-Parameters nach Präferenz ordnen (ähnlich den qvalues, die in Feldern der Inhaltsaushandlung verwendet werden, Abschnitt 5.3.1 von [RFC7231]). Der Rangwert ist eine reelle Zahl im Bereich von 0 bis 1, wobei 0.001 der am wenigsten bevorzugte und 1 der am meisten bevorzugte Wert ist; ein Wert von 0 bedeutet "nicht akzeptabel".

Wenn der Feldwert von TE leer ist oder kein TE-Feld vorhanden ist, ist die einzige akzeptable Transferkodierung chunked. Eine Nachricht ohne Transferkodierung ist immer akzeptabel.

Da das Header-Feld TE nur auf die unmittelbare Verbindung anwendbar ist, muss ein Absender von TE auch eine "TE"-Verbindungsoption im Header-Feld Connection senden (Abschnitt 6.1), um zu verhindern, dass das TE-Feld von Vermittlern weitergeleitet wird, die seine Semantik nicht unterstützen.

4.4. Trailer​

Wenn eine Nachricht einen mit der chunked-Transferkodierung kodierten Nachrichtenkörper enthält und der Absender Metadaten in Form von Trailer-Feldern am Ende der Nachricht senden möchte, SOLLTE der Absender vor dem Nachrichtenkörper ein Header-Feld Trailer erzeugen, um anzugeben, welche Felder in den Trailern vorhanden sein werden. Dies ermöglicht es dem Empfänger, sich auf den Empfang dieser Metadaten vorzubereiten, bevor er mit der Verarbeitung des Körpers beginnt, was nützlich ist, wenn die Nachricht gestreamt wird und der Empfänger eine Integritätsprüfung im laufenden Betrieb bestätigen möchte.

Trailer = 1#field-name