0

In the HTTP 1.1 Standard, it says that "If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent."

Which means that a server can, for example, return a gzip-encoded response body if the accept-encoding field is omitted.

In practice however, it seems like most commonly used servers (e.g. Apache, nginx) will not do this, and will send an uncompressed response if the field is omitted.

Is it fair to say that the more colloquial behavior is to only use encodings which are explicitly suggested by the client? This seems like a more logical course of action -- having the client give a list of encodings it can handle -- despite being contrary to the standard.

CaptainCodeman
  • 207
  • 1
  • 7

1 Answers1

0

No encoding is assumed to be acceptable even if no Accept-Encoding headers exist. Lacking any other guidance, not bothering to compress is a common choice. Saves work, explicitly allowed by spec.

If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity".

Or, when not provided Accept-Encoding a implementation could pick whatever it wants via some algorithm. Skipping content negotiation has the slight risk that the client doesn't know what to do with the encoding. Personally, I would like Content-Encoding: zstd but as of 2022 it is not common in user agents.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • This is what I mean though, you say "could pick whatever it wants", which is what the standard says, but by that logic a server could very well pick something that is not supported by the client which is silly. So then it follows that the more logical course of action would be to only use an encoding which is explicitly requested by the client? – CaptainCodeman Apr 25 '22 at 06:42