Accept Encoding Header

Accept Encoding Header

Copyright © Shutterstock / Ruslan Khismatov

Was ist Accept Encoding Header?

Ein Accept Encoding Header gibt bekannt, welche Inhaltscodierung eines Komprimierungsalgorithmus ein Client verstehen kann. Ein Client ist ein Computerprogramm, welches auf dem Endgerät eines Netzwerkes Applikationen ausführt und mit einem Server kommuniziert. Bei der Erörterung des Inhaltes wählt der Server einen der Vorschläge aus, verwendet ihn und informiert den Client seiner Wahl mit dem Antwortkopf der sogenannten Content Encoding Funktion.

Syntax Beispiel

Accept-Encoding: gzip,deflate

Funktion des Accept Encoding Header

Der Client als auch der Server unterstützen dieselben Komprimierungsalgorithmen. Dennoch kann der Server entscheiden, den Hauptteil einer Antwort nicht zu komprimieren, wenn der Identitätswert akzeptabel anerkannt wurde. Hierzu kann es häufig in den folgenden Fällen kommen:

Die zu sendenden Daten sind bereits komprimiert und eine zweite Komprimierung führt nicht zu kleineren zu übertragenden Daten. Dies kann bei einigen Bildformaten der Fall sein.
Der Server kann sich den durch die Komprimierungsanforderung verursachten Rechenaufwand nicht leisten. In der Regel empfiehlt z. B. Microsoft, nicht zu komprimieren, wenn ein Server mehr als 80 % seiner Rechenleistung verbraucht.

 

Hinweis

Solange der Identitätswert nicht explizit verboten ist (d. h. nicht codiert ist), darf der Server durch eine Identität – nämlich q=0 oder a* ;q=0 ohne einen anderen explizit gesetzten Wert für die Identität – niemals einen sogenannten Statuscode 406 Not Acceptable zurücksenden.

Allgemeine Formate des Accept Encoding Header

Die sogenannten Accept Encoding Header Felder werden nach der Anfrage- oder Antwortzeile gesendet, welche die erste Zeile einer Nachricht ergeben. Bei diesen Feldern handelt es sich um durch einen Doppelpunkt getrennte Name-Wert-Paare im Klartext-String-Format, die durch einen Wagenrücklauf- (CR), einen Zeilenvorschub (LF) sowie eine -Zeichenfolge, beendet werden. Das Ende des Header Abschnitts wird durch ein leeres Feld (Zeile) angezeigt, welches zur Übertragung von zwei aufeinanderfolgenden CR-LF-Paaren geführt wird.

In der Vergangenheit konnten lange Linien in mehrere Linien gefaltet werden – Fortsetzungszeilen wurden durch das Vorhandensein eines Leerzeichens (SP) oder einer horizontalen Registerkarte (HT) als erstes Zeichen in der nächsten Zeile angezeigt. Diese Faltung ist jetzt allerdings veraltet.

Ein Kernsatz von Feldern wird von der Internet Engineering Task Force (IETF) in den RFCs 7230, 7231, 7233, 7234 und 7235 standardisiert. Die permanente Registrierung der Header Felder und des Repositoriums (Ablage für Dokumente, Daten, Objekte, Programme und Metadaten) der provisorischen Registertrennungen wird von der IANA gepflegt. Zusätzliche Feldnamen und zulässige Werte können von jeder Anwendung definiert werden.
Einige Felder können Kommentare enthalten (z. B. in den Feldern User Agent, Server, Via), die von der Software ignoriert werden können. Viele Feldwerte können eine Schlüssel-/Wert-Paar-Qualität (q) enthalten, die eine Gewichtung für die Inhaltsverhandlung angeben.

Größenbeschränkungen

Der Standard schreibt der Größe jedes Header Feldnamens oder -wertes oder der Anzahl der Felder keine Grenzen vor. Die meisten Server, Clients oder Proxy Softwares setzen jedoch aus praktischen und sicherheitsrelevanten Gründen Grenzen. Der Apache 2.3 Server begrenzt z. B. standardmäßig die Größe jedes Feldes auf 8,190 Bytes und es können maximal 100 Header Felder in einer einzigen Anfrage vorhanden sein.

Auswirkungen: Vermeidung des Zwischenspeicherns

Wenn ein Webserver mit Cache Control: no-cache antwortet, darf ein Webbrowser oder ein anderes Cache System (Zwischenproxys) die Antwort nicht verwenden, um nachfolgende Anforderungen zu erfüllen, ohne zuerst den Ursprungsserver zu überprüfen (dieser Vorgang wird Validierung genannt). Dieses Header Feld ist ein Teil von HTTP Version 1.1 und wird von einigen Caches und Browsern ignoriert.

Es ist eine Simulierung möglich, indem der Expires HTTP Version 1.0 Header Feldwert auf einen Zeitpunkt festgelegt wird, der von der Antwortzeit liegt. Hierbei ist zu beachten, dass das No-Cache den Browser oder die Proxys nicht darüber informiert, ob der Inhalt zwischengespeichert werden soll oder nicht. Es teilt dem Browser und den Proxys lediglich mit, dass der Cache Inhalt mit dem Server validiert, bevor es verwendet werden kann.

Dies geschieht anhand folgender Attribute:

Das Senden eines Nicht-Cache-Wertes weist daher einen Browser oder Proxy an, den Cache Inhalt nicht einfach auf der Basis von “Frischekriterien” des Cache Inhaltes zu verwenden. Eine weitere gängige Methode, um zu verhindern, dass alte Inhalte ohne Validierung dem Benutzer angezeigt werden, ist Cache Control: max-age = 0. Dies weist den Benutzeragenten an, dass der Inhalt veraltet ist und vor der Verwendung überprüft werden sollte.

Tipp

Das Header Feld Cache Control: no-store soll eine Browseranwendung anweisen, sich zu bemühen den Inhalt nicht auf der Festplatte zu schreiben. Damit ist gemeint, dass von einem Zwischenspeichern abgesehen werden soll.

Die Anforderung, dass eine Ressource nicht zwischengespeichert werden soll, ist keine Garantie dafür, dass sie nicht auf die Festplatte geschrieben wird. Insbesondere unterscheidet die HTTP / 1.1 Definition zwischen Verlaufsspeichern und Caches.

Wenn der Benutzer zu einer vorherigen Seite zurück navigiert, zeigt ein Browser möglicherweise noch eine Seite an, die auf der Festplatte im Verlaufsspeicher gespeichert wurde. Dies ist das korrekte Verhalten gemäß der Spezifikation. Viele Benutzeragenten zeigen ein unterschiedliches Verhalten beim Laden vonseiten aus dem Verlaufsspeicher oder Cache, je nachdem, ob das Protokoll HTTP oder HTTPS ist.

Das Header Feld Cache Control: No-Cache HTTP / 1.1 ist auch für die Verwendung in Anforderungen des Clients vorgesehen. Es ist eine Möglichkeit für den Browser, dem Server und allen Zwischencaches mitzuteilen, dass eine neue Version der Ressource gewünscht wird. Das Header Feld Pragma: No-Cache, das in der HTTP / 1.0 Spezifikation definiert ist, hat den gleichen Zweck.

Es ist jedoch nur für den Anforderungsheader definiert. Seine Bedeutung in einem Antwortheader ist nicht spezifiziert. Das Verhalten von Pragma-No-Cache in einer Antwort ist implementierungsspezifisch. Während einige Benutzerprogramme dieses Feld in Antworten beachten, warnt der HTTP / 1.1 RFC ausdrücklich davor, sich auf dieses Verhalten zu verlassen.


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte