The Accept-Encoding request HTTP header indicates the content encoding (usually a compression algorithm) that the client can understand. The server uses content negotiation to select one of the proposals and informs the client of that choice with the Content-Encoding response header.
Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the identity value is also acceptable. Two common cases lead to this:
- The data to be sent is already compressed, therefore a second compression will not reduce the transmitted data size. This is true for pre-compressed image formats (JPEG, for instance);
- The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.
As long as the identity;q=0 or *;q=0 directives do not explicitly forbid the identity value that means no encoding, the server must never return a 406 Not Acceptable error.
Note:
- An IANA registry maintains a complete list of official content encodings.
- Two other content encodings, namely
bzipandbzip2, are sometimes used, These non-standard encodings implement the algorithm that these two UNIX programs use. Note thatbzipwas discontinued due to patent licensing issues.
| Header type | Request header |
|---|---|
| Forbidden header name | yes |