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 Transfer-Encoding-Header gibt die Form der Kodierung an, die zum Übertragen von Nachrichten zwischen Knoten im Netzwerk verwendet wird.

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

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 Multi-Knoten-Verbindung 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 der Antwort auf eine HEAD-Anfrage vorhanden ist, die keinen Body hat, gibt er den Wert an, der auf die entsprechende GET-Nachricht angewendet worden wäre.

Header-Typ Request header, Response header, Content header
Verbotener Header-Name 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 Blöcken gesendet. Der Content-Length-Header wird in diesem Fall weggelassen und am Anfang jedes Blocks muss die Länge des aktuellen Blocks in hexadezimalem Format hinzugefügt werden, gefolgt von \r\n und dann dem Block selbst, gefolgt von einem weiteren \r\n. Der abschließende Block ist ein regulärer Block, mit der Ausnahme, dass seine Länge null ist. Er wird vom Trailer gefolgt, der aus einer (möglicherweise leeren) Sequenz von Header-Feldern besteht.

compress

Ein Format unter Verwendung des Lempel-Ziv-Welch (LZW)-Algorithmus. Der Wertename wurde vom UNIX-Programm compress übernommen, das diesen Algorithmus implementierte. Wie das Compress-Programm, das von den meisten UNIX-Distributionen verschwunden ist, wird diese Content-Encoding heutzutage von fast keinem Browser mehr verwendet, teilweise aufgrund eines Patentproblems (das 2003 ablief).

deflate

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

gzip

Ein Format unter Verwendung der Lempel-Ziv-Kodierung (LZ77), mit einem 32-Bit-CRC. Dies ist ursprünglich das Format des UNIX-Programms gzip. Der HTTP/1.1-Standard empfiehlt auch, dass die Server, die dieses Content-Encoding unterstützen, x-gzip als Alias erkennen sollten, aus Kompatibilitätsgründen.

Beispiele

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 beim Generieren einer großen HTML-Tabelle, die aus einer Datenbankabfrage resultiert, oder beim Übertragen großer Bilder. 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