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.
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.
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.
Fastly automatically normalizes the value of
Accept-Encoding on inbound requests because it has a huge impact on cache performance when responses include
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
Fastly-Orig-Accept-Encodingto the value of
- If the
User-Agentmatches a pattern for browsers that have problems with compressed responses, remove the
- Else if the
Accept-Encodingheader includes the string "gzip", set the entire value to the string "gzip"
- Else if the
Accept-Encodingheader includes the string "deflate", set the entire value to the string "deflate"
- Else remove the
- If the
Accept-Encodingheader 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.
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.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.