1. Home
  2. Reference documentation
  3. HTTP references
  4. HTTP Headers

Accept-Encoding

Indicates the content encoding (usually a compression algorithm) that the client can understand.

Fastly reads this header from requests and writes it into requests. It is defined by an external standard.

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 proposal and informs the client of that choice with the Content-Encoding response header.

HINT: Accept, Accept-Encoding and Accept-Language are designed to allow for content negotiation. For content negotiation to work properly on content served through Fastly, the Vary header must be correctly set. See our blog post Getting the most out of Vary with Fastly for a discussion of the best practices and patterns that you may find useful.

Normalization

Fastly automatically normalizes the value of Accept-Encoding on inbound requests because it has a huge impact on cache performance when responses include Vary: Accept-Encoding.

Compression support is one of the most common reasons to vary output based on a request header - so that compressed content can be delivered to clients that support it, and uncompressed to those that don't. However, the number of possible permutations of Accept-Encoding on requests is large: for example, "deflate, gzip" and "gzip, deflate" are different strings but indicate support for the same compression standards.

The normalized header is set to a single encoding type, or none, and will reflect the best compression scheme supported by the browser. Specifically, we run the following steps on inbound requests before invoking vcl_recv:

  1. Set Fastly-Orig-Accept-Encoding to the value of Accept-Encoding.
  2. If the User-Agent matches a pattern for browsers that have problems with compressed responses, remove the Accept-Encoding header.
  3. Else if the Accept-Encoding header includes the string "gzip", set the entire value to the string "gzip"
  4. Else if the Accept-Encoding header includes the string "deflate", set the entire value to the string "deflate"
  5. Else remove the Accept-Encoding header

As part of the # FASTLY recv macro in vcl_recv (see using VCL) we run the following additional step for services that have brotli compression enabled:

  1. If the Accept-Encoding header includes the string "br", set the entire value to the string "br".

An origin server that supports and generates compressed responses should include Vary: Accept-Encoding in all responses where compression was considered, whether or not the response was actually compressed. When caching a response that contains such a Vary header, Fastly will only match it to future requests that carry the same Accept-Encoding header as the request that prompted the origin response.

If you prefer to normalize the value of Accept-Encoding yourself in a VCL service, see the accept.encoding_lookup function. Be sure to perform your normalization using req.http.Fastly-Orig-Accept-Encoding as a source, and do it after the #FASTLY recv macro has executed.

If you prefer to handle Accept-Encoding yourself on your origin, you can ignore the normalization with:

set req.http.Accept-Encoding = req.http.Fastly-Orig-Accept-Encoding;

Interaction with compression at the edge

Fastly supports compressing HTTP responses at the edge, using both GZip and (where enabled on your service) Brotli. This can be activated in our web interface or using the Fastly API. It's also possible to construct the same behavior manually using VCL code. See beresp.gzip and beresp.brotli for more details.

When content is compressed at the edge, it benefits from automatic normalization of Accept-Encoding in exactly the same way that origin-compressed content does.

Fastly
© Fastly 2024