Accept-Language

Indicates the natural language and locale that the client prefers.

This header is defined by an external standard.

The Accept-Language request HTTP header indicates the natural language and locale that the client prefers. The server uses content negotiation to select one of the proposals and informs the client of the choice with the Content-Language response header. Browsers set required values for this header according to their active user interface language.

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.

Fastly ignores this header but preserves it on requests. Origin servers that take notice of the value of Accept-Language on any request to a given URL and respond with content in a language matching that requested must include a Vary: Accept-Language on all responses for requests to that same URL. This enables Fastly to store each language version of the content separately and ensure each user receives the right language.

Normalization

The number of possible permutations of Accept-Language values is very large, and if responses include Vary: Accept-Language, cache performance may noticably decline. Normalizing the value of Accept-Language on inbound requests can dramatically improve cache hit ratios in this situation.

Fastly does not normalize Accept-Language by default, but we provide utilities to make it easy to do so in VCL services. See accept.language_lookup and accept.language_filter_basic for more details.

User contributed notes

BETA

Do you see an error in this page? Do you have an interesting use case, example or edge case people should know about? Share your knowledge and help people who are reading this page! (Comments are moderated; for support, please contact Fastly support)