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-Header Transfer-Encoding
für Anfragen und Antworten 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 die Ressource selbst. Jeder Abschnitt 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 dieser in einer Antwort auf eine HEAD
-Anfrage erscheint, die keinen Körper hat, gibt er den Wert an, der auf die entsprechende GET
-Nachricht angewendet worden wäre.
Warnung:
HTTP/2 verbietet alle Anwendungen des Transfer-Encoding
-Headers mit Ausnahme des HTTP/2-spezifischen Wertes "trailers"
.
HTTP/2 und spätere Versionen bieten effizientere Mechanismen für Datenstreaming als Chunked Transfer.
Die Nutzung des Headers in HTTP/2 kann wahrscheinlich zu einem spezifischen protocol error
führen.
Header-Typ | Anfrage-Header, Antwort-Header, Inhalts-Header |
---|---|
Verbotener Headername | Ja |
Syntax
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. Inhalte können in Streams unbekannter Größe gesendet werden, um als eine Folge von längenbegrenzten Puffern übertragen zu werden, sodass der Absender eine Verbindung offen halten kann und der Empfänger erfährt, wenn die gesamte Nachricht empfangen wurde. Der
Content-Length
-Header muss weggelassen werden, und zu Beginn jedes Blocks gibt eine Zeichenkette aus Hexadezimalziffern die Größe der Block-Daten in Oktetten an, gefolgt von\r\n
und dann dem 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 Wertname stammt vom UNIX-Programm compress, das diesen Algorithmus implementierte. Wie das Compress-Programm, das von den meisten UNIX-Distributionen verschwunden ist, wird diese Inhaltskodierung heute von fast keinem Browser 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 die Lempel-Ziv-Codierung (LZ77) mit einer 32-Bit-CRC verwendet. Dies ist ursprünglich das Format des UNIX-Programms gzip. Der HTTP/1.1-Standard empfiehlt auch, dass die Server, die diese Inhaltskodierung 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 aus einer Datenbankabfrage generiert wird oder beim Übertragen großer Bilder. Eine chunked Antwort sieht so aus:
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
Accept-Encoding
Content-Encoding
Content-Length
- Header-Felder, die die Nutzung von Trailers regeln:
TE
(Anfragen) undTrailer
(Antworten). - Chunked Transfer Encoding