Content-Encoding

Verwendung

Der Content-Encoding-Header listet die auf die Repräsentationsdaten angewendeten Kodierungen in der Reihenfolge ihrer Anwendung auf. Der Client kehrt die Kodierungskette um, um den ursprünglichen Inhalt zu rekonstruieren. Komprimierung ist der häufigste Anwendungsfall: Sie verringert die Übertragungsgröße auf Kosten der CPU-Zeit auf Server- wie auf Client-Seite.

Der Accept-Encoding-Anfrage-Header gibt bekannt, welche Kodierungen der Client unterstützt. Der Server wählt eine Kodierung aus dieser Liste aus und teilt seine Wahl im Content-Encoding-Antwort-Header mit. Existiert keine akzeptable Kodierung, sendet der Server die Antwort unkomprimiert.

Ist Content-Encoding vorhanden, beziehen sich Metadaten-Header wie Content-Length auf die kodierte Form, nicht auf die ursprüngliche Ressource. Bereits komprimierte Medienformate wie JPEG, PNG und ZIP enthalten eine interne Komprimierung und profitieren kaum von einem zusätzlichen Kodierungsdurchlauf. Eine Content-Kodierung auf diese Formate anzuwenden verschwendet CPU-Zeit und vergrößert die Übertragung mitunter sogar.

Der Content-Encoding-Header beschreibt die Repräsentationskodierung, eine Ende-zu-Ende-Eigenschaft der Ressource. Das unterscheidet ihn von Transfer-Encoding, einer Hop-by-Hop-Eigenschaft, die an jedem Netzwerkvermittler angewendet und wieder entfernt wird.

Hinweis

gzip ist nach wie vor die am weitesten verbreitete Kodierung. Brotli bietet die besten Kompressionsraten für statische Textinhalte. Zstandard bietet ein ausgewogenes Verhältnis aus schneller Komprimierung und hohen Kompressionsraten bei breiter Browser-Unterstützung.

Hinweis

Der ursprüngliche Medientyp der Ressource wird durch den Content-Type-Header beschrieben. Content-Encoding spiegelt den Komprimierungszustand der aktuellen Repräsentation wider, nicht das Format des zugrunde liegenden Inhalts.

gzip

Der Lempel-Ziv-Kodierungsalgorithmus (LZ77) mit einer 32-Bit-CRC. 1996 eingeführt, ist gzip bis heute die am breitesten unterstützte Kodierung im Web. Server erkennen auch x-gzip als Alias.

compress

Der Lempel-Ziv-Welch-Algorithmus (LZW), ursprünglich aus dem UNIX-Programm compress. Patentbedenken führten zum Niedergang des Algorithmus, und kein moderner Browser unterstützt compress.

deflate

Die zlib-Struktur, die den deflate-Algorithmus umschließt. Wird von allen Browsern unterstützt, ist aber weitgehend durch gzip und neuere Algorithmen abgelöst worden.

br

Der Brotli-Algorithmus. Brotli erreicht höhere Kompressionsraten als gzip, insbesondere bei textbasierten Web-Inhalten, indem es ein eingebautes statisches Wörterbuch gängiger Web-Begriffe verwendet. Brotli setzt HTTPS voraus. Wird von allen gängigen Browsern unterstützt.

zstd

Der Zstandard-Algorithmus. Zstandard komprimiert mit einer Geschwindigkeit, die mit gzip vergleichbar ist, und erreicht dabei Kompressionsraten nahe an Brotli. Der Algorithmus unterstützt konfigurierbare Kompressionsstufen von 1 (am schnellsten) bis 22 (höchste Rate), sodass Server CPU-Zeit gegen kleinere Nutzlasten eintauschen können. Die Dekomprimierungsgeschwindigkeit bleibt unabhängig von der verwendeten Kompressionsstufe durchgehend hoch.

Zstandard unterstützt außerdem wörterbuchbasierte Komprimierung: Ein vorab geteiltes, auf repräsentativen Inhalten trainiertes Wörterbuch verringert die Nutzlastgrößen weiter. Der Use-As-Dictionary-Header und der Mechanismus Compression Dictionary Transport bauen auf dieser Fähigkeit auf.

Wird von Chromium-basierten Browsern, Firefox und neueren Safari-Versionen unterstützt.

dcb

Wörterbuchkomprimiertes Brotli. Definiert als Teil der Spezifikation Compression Dictionary Transport. Client und Server handeln über die Header Use-As-Dictionary und Available-Dictionary ein gemeinsames Wörterbuch aus. Der Server komprimiert die Antwort mit Brotli unter Verwendung des gemeinsamen Wörterbuchs und signalisiert die Kodierung als dcb.

dcz

Wörterbuchkomprimiertes Zstandard. Verwendet denselben Wörterbuch-Transportmechanismus wie dcb, jedoch mit dem Zstandard-Algorithmus statt Brotli. Der Server komprimiert mit dem ausgehandelten Wörterbuch und signalisiert die Kodierung als dcz.

Beispiel

Eine mit gzip komprimierte Antwort. Dies ist die häufigste Kodierung im Web und wird von allen Browsern unterstützt.

Content-Encoding: gzip

Eine mit Brotli komprimierte Antwort. Brotli erzeugt bei HTML-, CSS- und JavaScript-Ressourcen typischerweise kleinere Nutzlasten als gzip.

Content-Encoding: br

Eine mit Zstandard komprimierte Antwort. Server, die sich für Zstandard entscheiden, profitieren von schneller Komprimierung bei Kompressionsraten, die mit Brotli vergleichbar sind.

Content-Encoding: zstd

Mehrere nacheinander angewendete Kodierungen. Die Ressource wurde zuerst mit deflate und anschließend mit gzip kodiert. Der Client dekodiert in umgekehrter Reihenfolge: zuerst gzip, dann deflate.

Content-Encoding: deflate, gzip

Eine Antwort mit wörterbuchkomprimiertem Zstandard. Der Client hat zuvor über den Use-As-Dictionary-Header ein Wörterbuch erhalten und dieses Wörterbuch im Available-Dictionary-Anfrage-Header angekündigt. Der Server hat die Antwort gegen das gemeinsame Wörterbuch komprimiert.

Content-Encoding: dcz

Fehlersuche

Komprimierungsbedingte Fehler äußern sich als Dekodierungsfehler im Browser, als beschädigte Downloads oder als Antworten, die unkomprimiert eintreffen.

Doppelte Komprimierung erzeugt beschädigte Antworten. Ein Reverse-Proxy oder ein CDN komprimiert eine bereits komprimierte Antwort vom Ursprungsserver erneut und erzeugt so eine ungültige Nutzlast, die der Client nicht dekodieren kann. Prüfen Sie den Content-Encoding-Header auf gestapelte Werte wie gzip, gzip. Deaktivieren Sie in nginx die Proxy-Komprimierung, wenn der Ursprungsserver bereits komprimiert:

proxy_set_header Accept-Encoding "";

Deaktivieren Sie in Cloudflare “Brotli” in den Speed-Einstellungen, wenn der Ursprungsserver vorkomprimierte Antworten sendet.

Der Browser zeigt ERR_CONTENT_DECODING_FAILED. Dieser Fehler tritt auf, wenn der Content-Encoding-Header eine Kodierung angibt, die nicht zum tatsächlichen Inhalt des Bodys passt. Häufige Ursachen: Der Ursprungsserver sendet einen unkomprimierten Body mit Content-Encoding: gzip, oder eine Middleware entfernt die Kodierung, lässt den Header aber unangetastet. Führen Sie curl -v -H “Accept-Encoding: gzip” https://example.re aus und prüfen Sie, ob der Roh-Body zur deklarierten Kodierung passt. Zur Verifikation durch gunzip leiten: curl -s —compressed https://example.re | head.

Content-Length stimmt nach der Komprimierung nicht. Der Content-Length-Wert muss die Größe des komprimierten Bodys widerspiegeln, nicht die ursprüngliche Größe. Eine Abweichung führt dazu, dass Browser die Antwort abschneiden oder ablehnen. Bei Verwendung von nginx gzip on berechnet nginx Content-Length automatisch neu. Middleware, die Content-Length setzt, bevor die Komprimierung läuft, verursacht dieses Problem. Verlegen Sie die Zuweisung von Content-Length hinter die Komprimierung, oder entfernen Sie den Header und lassen Sie den Server ein gechunktes Transfer-Encoding verwenden.

Komprimierung wird trotz Serverkonfiguration nicht angewendet. Der Server prüft vor dem Komprimieren den Accept-Encoding-Anfrage-Header. Ein fehlender oder leerer Accept-Encoding-Header bedeutet keine Komprimierung. Manche Proxys entfernen Accept-Encoding aus weitergeleiteten Anfragen. Stellen Sie in nginx sicher, dass gzip on gesetzt ist und die MIME-Typen übereinstimmen:

gzip on;
gzip_types text/plain application/json
           text/css application/javascript;

Aktivieren Sie in Apache mod_deflate und prüfen Sie, dass der Filter angewendet wird:

AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE application/json

Vorkomprimierte Dateien ausliefern für bessere Performance. Bei jeder Anfrage neu zu komprimieren verschwendet CPU-Zeit. Liefern Sie statische Dateien stattdessen vorkomprimiert von der Festplatte aus. Aktivieren Sie in nginx gzip_static on, um .gz-Dateien neben den Originalen auszuliefern. Aktivieren Sie in Apache MultiViews oder verwenden Sie mod_rewrite, um Anfragen auf .gz- oder .br-Varianten abzubilden. Stellen Sie sicher, dass die vorkomprimierten Dateien bei Deployments mit den Originalen synchron bleiben.