HTTP Headers
Accept Encoding
The HTTP Accept-Encoding
request and response headers specify the content encoding, typically a compression algorithm, that the sender can interpret.
In requests, the server employs content negotiation to select an encoding proposal from the client and informs the client of this selection through the Content-Encoding
response header.
In responses, it provides details about which content encodings the server supports, allowing the client to use the same encoding in subsequent requests to the resource.
For example, if a request uses an unsupported encoding, the server responds with 415 Unsupported Media Type
. In such cases, Accept-Encoding
can be involved in error responses.
Even when both the client and server support the same compression algorithms, the server may opt not to compress the response body if the identity
encoding is also acceptable.
This typically occurs in two situations:
- The data is already compressed, such as in JPEG images or other pre-compressed formats, where additional compression will not reduce size and may increase it.
- The server is experiencing high load and lacks the resources to perform compression effectively.
For example, Microsoft recommends avoiding compression if the server’s CPU utilization exceeds 80%.
Provided that directives like identity;q=0
or *;q=0
do not explicitly prohibit the identity
encoding (meaning no encoding), the server should never return a 406 Not Acceptable
error.
Header type | Request header, Response header |
---|---|
Forbidden request header | Yes |
Syntax
Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: zstd
Accept-Encoding: dcb
Accept-Encoding: dcz
Accept-Encoding: identity
Accept-Encoding: *
// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
Directives
- gzip
- A compression format that uses the Lempel-Ziv coding (LZ77) with a 32-bit CRC.
- compress
- A compression format that utilizes the Lempel-Ziv-Welch (LZW) algorithm.
- deflate
- This compression method employs the zlib structure combined with the deflate algorithm for efficient data compression.
- br
- A compression format that leverages the Brotli algorithm, offering high compression ratios.
- zstd
- This format uses the Zstandard compression algorithm, designed for fast and efficient compression.
- dcb
- A format utilizing the Dictionary-Compressed Brotli algorithm. See Compression Dictionary Transport for more details.
- dcz
- A format that adopts the Dictionary-Compressed Zstandard algorithm. Refer to Compression Dictionary Transport for additional information.
- identity
- Indicates the identity function, meaning no modification or compression is applied. This value is always considered acceptable, even if not explicitly specified.
- * (wildcard)
- Represents any content encoding not explicitly listed. This is the default when no header is present and indicates that no specific preference is expressed. It does not guarantee support for any particular algorithm.
- ;q=
- This parameter assigns a weight indicating preference among content encodings, using a relative quality value.
Example
Default Accept-Encoding values
Browsers typically send a request header named Accept-Encoding
with major compression algorithms they support. An example of such a header is:
GET /en-US/ HTTP/2
Host: developer.mozilla.org
Accept-Encoding: gzip, deflate, br, zstd
Weighted Accept-Encoding values
The following header demonstrates the client’s preferences for content encodings using quality values between 0
(lowest preference) and 1
(highest preference). Brotli compression has the highest priority with a weight of 1.0</>, meaning it is the client's first choice. This is followed by gzip with a weight of
0.8
, and all other encodings are considered least preferred with a weight of 0.1
.
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
How to Modify Header using Requestly
Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Accept header. This is especially useful for testing how your application responds to different media types during development or debugging. Steps to Modify the Accept Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Accept.
- In the “Header Value” field, enter your preferred media type (e.g., text/html).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
- Save the rule.
Once set up, Requestly will inject the Accept: text/html header into all matching requests, allowing you to simulate different client behaviors and test content negotiation on your server.
You might need to modify the Accept header to test how your website or API responds to different content types, like HTML, JSON, or XML. This helps ensure your app works correctly with various clients and data formats.
Table of Contents
- No headings found.