Accept-Encoding

Verwendung

Der HTTP-Anfrage-Header Accept-Encoding ist Teil der Inhaltsaushandlung und gibt an, welche Kodierungsverfahren der Client unterstützt. Der Server wählt eines der verfügbaren Verfahren aus und teilt dem Client die Auswahl anschließend mit, indem er den Header Content-Encoding in die HTTP-Antwort aufnimmt.

Hinweis

In manchen Fällen wird die ursprüngliche Ressource vor dem Senden nicht verändert, selbst wenn Client und Server dieselben Kodierungsverfahren unterstützen. Das tritt in Situationen auf, in denen der Wert identity der Ressource ebenfalls akzeptabel ist. Ein häufiges Beispiel sind bereits komprimierte Daten, bei denen ein nachgelagerter Komprimierungsalgorithmus die Größe nicht weiter verringert. Das kommt bei vorkomprimierten Bilddateien wie JPEG vor. Eine andere Situation liegt vor, wenn der Server stark ausgelastet ist und die Ressourcen nicht erübrigen kann, die für eine Verarbeitung der Daten vor der Übertragung nötig wären.

Mehrere Kodierungen werden über getrennte HTTP-Header Accept-Encoding angegeben oder stattdessen über eine kommagetrennte Liste. Zusätzlich wird der q-Faktor angegeben, um eine Präferenz oder Priorität auszudrücken.

SEO-Auswirkung

Die Crawler und Fetcher von Google unterstützen die Inhaltskodierungen gzip, deflate und Brotli (br). Jeder Google-User-Agent gibt die unterstützten Kodierungen im Header Accept-Encoding jeder Anfrage an, typischerweise als Accept-Encoding: gzip, deflate, br. Komprimierte Antworten an den Googlebot auszuliefern reduziert Bandbreite und Crawling-Zeit. Der Bingbot sendet Accept-Encoding: gzip, deflate.

gzip

Die Direktive gzip zeigt an, dass der Client die GNU-zip-Komprimierung unterstützt. Das ist die im Web am weitesten unterstützte Kodierung.

deflate

Die Direktive deflate zeigt an, dass der Client die zlib-Komprimierung unterstützt. Dem Namen zum Trotz werden dabei die rohen DEFLATE-komprimierten Daten in eine zlib-Hülle verpackt.

br

Die Direktive br zeigt an, dass der Client die Brotli-Komprimierung unterstützt. Bei textbasierten Inhalten erreicht Brotli in der Regel bessere Kompressionsraten als gzip.

zstd

Die Direktive zstd zeigt an, dass der Client die Zstandard-Komprimierung unterstützt. Zstandard bietet hohe Kompressionsraten bei gleichzeitig schnellen Dekomprimierungsgeschwindigkeiten.

identity

Die Direktive identity zeigt an, dass keine Kodierung angewendet wird. Dieser Wert gilt immer als akzeptabel, sofern er nicht mit identity;q=0 ausdrücklich ausgeschlossen wird.

* (Platzhalter)

Der Platzhalter * passt auf jede Kodierung, die im Header nicht bereits aufgeführt ist. Ist kein Header Accept-Encoding vorhanden, behandelt der Server die Anfrage so, als wäre * angegeben worden.

;q= (Qualitätswert)

Der Parameter ;q= weist jeder Kodierung eine Gewichtung zwischen 0 und 1 zu, wobei 1 die höchste Priorität bedeutet und 0 “nicht akzeptabel”. Wird er weggelassen, beträgt der Standard-Qualitätswert 1. Der Server nutzt diese Gewichtungen, um die bevorzugte Kodierung auszuwählen.

Beispiel

In diesem Beispiel fordert der Client den Server auf, eines von mehreren Kodierungsverfahren zu verwenden. In der ersten Variante erhält jede der Optionen dieselbe Priorität. In der zweiten Variante wird die q-Wert-Direktive verwendet, um der Kodierungspriorität eine Gewichtung zuzuweisen. Der Server antwortet mit der Liste der angewendeten Kodierungen, geordnet nach der Reihenfolge ihrer Verarbeitung.

Anfrage (Variante #1)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

Anfrage (Variante #2)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25

Antwort

HTTP/1.1 200 OK
Content-Encoding: gzip, br

Fehlersuche

Trotz Accept-Encoding wird keine Komprimierung angewendet. Manche Reverse-Proxys entfernen Accept-Encoding vor dem Weiterleiten aus der Anfrage. In nginx erhält proxy_set_header Accept-Encoding $http_accept_encoding den ursprünglichen Wert. Prüfen lässt sich das mit curl -H “Accept-Encoding: gzip” -I.

Unerwartete Kodierung ausgewählt. Qualitätswerte (q-Faktoren) steuern die Reihenfolge der Präferenzen. Eine Anfrage mit Accept-Encoding: gzip;q=0.5, br;q=1.0 bevorzugt Brotli. Werden die q-Werte weggelassen, erhalten alle dieselbe Gewichtung und der Server wählt frei.

CORS-Preflight ohne Accept-Encoding. Der Header Accept-Encoding steht in CORS auf der Safelist und löst keinen Preflight aus. Falls die Komprimierung bei Cross-Origin-Anfragen nicht mehr funktioniert, prüfen Sie, ob der Server die Komprimierung unabhängig vom Header Origin anwendet.

CDN liefert unkomprimierte Antworten aus. Manche CDNs komprimieren nur dann, wenn der Ursprungsserver eine unkomprimierte Antwort mit einem passenden Content-Type sendet. Stellen Sie sicher, dass der Ursprungsserver mit Vary: Accept-Encoding antwortet, damit das CDN komprimierte und unkomprimierte Varianten getrennt zwischenspeichert.

Kodierung identity abgelehnt. Mit Accept-Encoding: identity;q=0 teilt der Client dem Server mit, dass er keine unkomprimierten Antworten akzeptieren kann. Steht keine unterstützte Kodierung zur Verfügung, gibt der Server 406 Not Acceptable zurück. Vermeiden Sie es, identity auf q=0 zu setzen, sofern nicht garantiert alle aufgeführten Kodierungen verfügbar sind.