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

TheAccept-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 theContent-Encoding response header.

Normalization

Fastly automatically normalizes the value ofAccept-Encoding on inbound requests because it has a huge impact on cache performance when responses includeVary: 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 ofAccept-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 invokingvcl_recv:

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

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

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

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

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

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

setreq.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. Seeberesp.gzip andberesp.brotli for more details.

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