Transfer-Encoding

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

Der HTTP-Transfer-Encoding-Anforderungs- und Antwort-Header gibt die Form der Codierung an, die verwendet wird, um Nachrichten zwischen Knoten im Netzwerk zu übertragen.

Transfer-Encoding ist ein Hop-by-hop-Header, der auf eine Nachricht zwischen zwei Knoten angewendet wird, nicht auf eine Ressource selbst. Jedes Segment einer Verbindung über mehrere Knoten kann unterschiedliche Transfer-Encoding-Werte verwenden. Wenn Sie Daten über die gesamte Verbindung komprimieren möchten, verwenden Sie stattdessen den end-to-end Content-Encoding Header.

Wenn er in einer Antwort auf eine HEAD-Anfrage ohne Körper vorhanden ist, gibt er den Wert an, der auf die entsprechende GET-Nachricht angewendet worden wäre.

Warnung: HTTP/2 verbietet alle Verwendungen des Transfer-Encoding-Headers, außer dem HTTP/2-spezifischen Wert "trailers". HTTP/2 und spätere Versionen bieten effizientere Mechanismen für die Datenübertragung als Chunked Transfer. Die Verwendung des Headers in HTTP/2 kann wahrscheinlich zu einem spezifischen protokollfehler führen.

Header-Typ Anforderungs-Header, Antwort-Header, Inhalts-header
Verbotener Anforderungs-Header Ja

Syntax

http
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip

// Several values can be listed, separated by a comma
Transfer-Encoding: gzip, chunked

Direktiven

chunked

Daten werden in einer Reihe von Chunks gesendet. Inhalte können als Streams unbekannter Größe gesendet werden, um als eine Folge von längengesteuerten Puffern übertragen zu werden, sodass der Absender eine Verbindung offenhalten kann und der Empfänger weiß, wann er die gesamte Nachricht erhalten hat. Der Content-Length Header muss weggelassen werden, und zu Beginn jedes Chunks gibt eine Zeichenfolge aus hexadezimalen Ziffern die Größe der Chunk-Daten in Oktetten an, gefolgt von \r\n und dann dem Chunk selbst, gefolgt von einem weiteren \r\n. Der abschließende Chunk ist ein Null-Längen-Chunk.

compress

Ein Format, das den Lempel-Ziv-Welch (LZW) Algorithmus verwendet. Der Wertname stammt aus dem UNIX-Programm compress, das diesen Algorithmus implementierte. Wie das Compress-Programm, das aus den meisten UNIX-Distributionen verschwunden ist, wird diese Content-Encoding heute von fast keinen Browsern mehr verwendet, teilweise wegen eines Patentproblems (das 2003 abgelaufen ist).

deflate

Verwendung der zlib-Struktur (definiert in RFC 1950) mit dem deflate-Kompressionsalgorithmus (definiert in RFC 1951).

gzip

Ein Format, das das Lempel-Ziv-Kodierung (LZ77) verwendet, mit einer 32-Bit-CRC. Dies ist ursprünglich das Format des UNIX-Programms gzip. Der HTTP/1.1-Standard empfiehlt auch, dass Server, die diese Inhaltscodierung unterstützen, x-gzip als Alias erkennen, aus Kompatibilitätsgründen.

Beispiele

Antwort mit chunked Encoding

Chunked Encoding ist nützlich, wenn größere Datenmengen an den Client gesendet werden und die Gesamtgröße der Antwort möglicherweise nicht bekannt ist, bis die Anfrage vollständig verarbeitet wurde. Zum Beispiel, wenn eine große HTML-Tabelle generiert wird, die aus einer Datenbankabfrage resultiert, oder wenn große Bilder übertragen werden. Eine chunked Antwort sieht folgendermaßen aus:

http
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
11\r\n
Developer Network\r\n
0\r\n
\r\n

Spezifikationen

Specification
HTTP/1.1
# field.transfer-encoding

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch