ImHTTP 1.1-Standardheißt es: „Wenn die Anforderung kein Accept-Encoding-Feld enthält, wird jede Inhaltscodierung vom Benutzeragenten als akzeptabel betrachtet.“
Das bedeutet, dass ein Server beispielsweise einen gzip-codierten Antworttext zurückgeben kann, wenn das Accept-Encoding-Feld weggelassen wird.
In der Praxis scheint es jedoch so, dass die meisten häufig verwendeten Server (z. B. Apache, nginx) dies nicht tun und eine unkomprimierte Antwort senden, wenn das Feld weggelassen wird.
Ist es fair zu sagen, dass das umgangssprachlichere Verhalten darin besteht, nur Kodierungen zu verwenden, die vom Client ausdrücklich vorgeschlagen werden? Dies scheint eine logischere Vorgehensweise zu sein – den Client eine Liste der Kodierungen bereitstellen zu lassen, die er verarbeiten kann – obwohl dies dem Standard widerspricht.
Antwort1
Es wird davon ausgegangen, dass keine Kodierung akzeptabel ist, selbst wenn keine Accept-EncodingHeader vorhanden sind. In Ermangelung anderer Richtlinien wird häufig auf die Komprimierung verzichtet. Das spart Arbeit und ist in der Spezifikation ausdrücklich erlaubt.
Wenn die Darstellung keine Inhaltscodierung aufweist, ist sie standardmäßig akzeptabel, sofern sie nicht ausdrücklich durch das Feld „Accept-Encoding“ mit der Angabe „identity;q=0“ oder „*;q=0“ ohne einen spezifischeren Eintrag für „identity“ ausgeschlossen wird.
Oder, wenn es nicht bereitgestellt wird, Accept-Encodingkönnte eine Implementierung über einen Algorithmus auswählen, was sie will. Das Überspringen der Inhaltsverhandlung birgt das geringe Risiko, dass der Client nicht weiß, was er mit der Kodierung tun soll. Persönlich würde ich das gerne tun, Content-Encoding: zstdaber ab 2022 ist es in Benutzeragenten nicht üblich.