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-Anfrage und -Antwort-Header gibt die Form der Kodierung 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 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 einer Antwort auf eine HEAD-Anfrage ohne Body vorhanden ist, zeigt er den Wert an, der der entsprechenden GET-Nachricht zugeordnet 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 Daten-Streaming als chunked Transfer. Die Verwendung des Headers in HTTP/2 kann wahrscheinlich zu einem spezifischen protocol error führen.

Header-Typ Anfrage-Header, Antwort-Header, Inhalts-Header
Verbotener Anfrage-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 Blöcken gesendet. Inhalt kann in Streams unbekannter Größe gesendet werden, um als eine Sequenz von längen-begrenzten Puffern übertragen zu werden, sodass der Sender die Verbindung offen halten kann und der Empfänger weiß, wann er die gesamte Nachricht empfangen hat. Der Content-Length-Header muss weggelassen werden, und zu Beginn jedes Blocks zeigt eine Zeichenfolge von hexadezimalen Ziffern die Größe der Blockdaten in Oktetten an, gefolgt von \r\n und dann der Block selbst, gefolgt von einem weiteren \r\n. Der abschließende Block ist ein Block mit null Länge.

compress

Ein Format, das den Lempel-Ziv-Welch (LZW)-Algorithmus verwendet. Der Wertename stammt vom UNIX-compress-Programm, das diesen Algorithmus implementierte. Wie das compress-Programm, das von den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltkodierung heute von fast keinem Browser 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 die Lempel-Ziv-Kodierung (LZ77) mit einer 32-Bit-CRC nutzt. Dies ist ursprünglich das Format des UNIX-gzip-Programms. Der HTTP/1.1-Standard empfiehlt auch, dass die Server, die diese Inhaltkodierung unterstützen, x-gzip als Alias erkennen, aus Gründen der Kompatibilität.

Beispiele

Antwort mit chunked Kodierung

Chunked Kodierung 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 so 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