Indicates which content types, expressed as MIME types, the client is able to understand.
This header is defined by an external standard.
Accept request HTTP header indicates which content formats, expressed as MIME types, the client is able to understand. A server can use this information to select a suitable format for the response and informs the client of the choice with the
Content-Type response header. Browsers set required values for this header based on the context of the request. For example, a browser uses different values in a request when fetching a CSS stylesheet, compared with an image, video, or an HTML page.
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 ignores this header but preserves it on requests. Origin servers that take notice of the value of
Accept on any request to a given URL and respond with content in a format matching that requested must include a
Vary: Accept on all responses for requests to that same URL. This enables Fastly to store each differently-formatted version of the content separately and ensure each user receives the right one.
A common use case for content-negotiation based on
Accept: application/json header.
The number of possible permutations of
Accept values is very large, and if responses include
Vary: Accept, cache performance may noticeably decline. Normalizing the value of
Accept on inbound requests can dramatically improve cache hit ratios in this situation.
Fastly does not normalize
Accept by default, but we provide utilities to make it easy to do so in VCL services. See
accept.media_lookup for more details.