Content Negotiation

The standard HTTP mechanism where the client sends preference headers and the server algorithmically selects the best matching variant. The Accept-Language header triggers language selection, Accept handles media types (e.g., JSON vs. HTML), and Accept-Encoding manages compression (gzip, br). The server examines these headers against its available representations and returns the single best match, setting the Vary response header to inform caches which request headers were used in the selection process.

An alternative pattern where the client actively chooses from available variants after receiving an initial response. When a server receives a request with ambiguous preferences, it responds with a 300 Multiple Choices or 406 Not Acceptable status code, providing a list of available representations. The client then programmatically selects the most appropriate variant and issues a second request. This approach gives the client full control but incurs an additional round-trip latency penalty.

HTTP uses relative quality weighting to express preference granularity. A header like Accept-Language: de;q=0.8, en;q=0.5, fr;q=0.2 tells the server: 'I prefer German most (0.8), then English (0.5), and French is least acceptable (0.2).' The q parameter ranges from 0 to 1, with 1 being the default when omitted. Servers evaluate these weighted preferences against their available variants, selecting the representation with the highest combined quality score that matches an available resource.

A caching-optimized variant where the server exposes all available representations upfront via the Alternates response header or a type map file. Intermediate caches and proxies can then perform negotiation on the server's behalf without forwarding every request to the origin. This reduces origin server load significantly for high-traffic multilingual sites. The cache examines the client's Accept-* headers, matches them against the pre-declared variant list, and serves the appropriate representation directly from cache.

The Vary response header is the linchpin of cache coherence in content negotiation. When a server selects a variant based on Accept-Language, it must respond with Vary: Accept-Language to prevent a French-speaking user from receiving a cached English page. Without this header, downstream caches would serve the first cached variant to all subsequent requests regardless of their language preferences. Multiple headers can be specified: Vary: Accept-Language, Accept-Encoding ensures both language and compression variants are correctly cached.

Content negotiation extends beyond language to multiple orthogonal dimensions simultaneously. A single request can negotiate:

• Media Type: Accept: text/html, application/json
• Language: Accept-Language: ja, en
• Encoding: Accept-Encoding: gzip, br
• Character Set: Accept-Charset: utf-8, iso-8859-1

The server must find the optimal combination across all dimensions, which becomes a combinatorial optimization problem when many variants exist.

The primary HTTP request header used in server-driven content negotiation. The client sends a prioritized list of language tags (e.g., Accept-Language: fr-CH, fr;q=0.9, en;q=0.8) to indicate its preferred natural languages. The server parses this header against its available representations and returns the best match. The q parameter defines a relative quality factor on a scale of 0 to 1, allowing clients to express fallback preferences.

The standard model where the server selects the best representation based on client headers. The server examines Accept, Accept-Language, Accept-Encoding, and Accept-Charset headers to determine the appropriate variant.

• Advantage: Single URI for all variants; simple client logic.
• Disadvantage: Server must have complete knowledge of all variants; limited client control.
• Vary Header: The server must include Vary: Accept-Language in responses to instruct caches that the response depends on that header.

An alternative model where the client selects the representation after receiving an initial response listing available variants. The server returns a 300 Multiple Choices or 406 Not Acceptable status code with a list of URIs and metadata for each variant. The client then makes a second request to the chosen URI.

• Use Case: When server-side selection heuristics are insufficient or the client needs explicit user input.
• Trade-off: Requires two round trips, increasing latency.

A critical HTTP response header that governs cache behavior in content negotiation. It instructs intermediary caches (CDNs, proxies) that the response body varies based on specific request headers.

• Vary: Accept-Language — Cache must store separate versions per language.
• Vary: Accept-Encoding — Cache must store separate versions per compression method.
• Vary: Accept-Language, Accept-Encoding — Cache must segment on both dimensions.

Without this header, a CDN might serve a French page to an English-speaking user.

A resolution mechanism that defines a chain of preferred locales when an exact match is unavailable. If a user requests fr-CA (French as spoken in Canada) and that variant doesn't exist, the system falls back to fr (generic French), then to the default locale (e.g., en).

• Algorithm: Longest-prefix matching on language tags.
• Implementation: Often configured in i18n libraries like ICU or framework-level locale resolvers.
• Relationship: Complements server-driven negotiation by handling partial matches gracefully.

The programmatic creation of HTML link elements that signal to search engines the language and regional targeting of alternate page versions. Each variant gets an <link rel="alternate" hreflang="es-MX" href="https://example.com/mx/" /> tag.

• Prevents duplicate content penalties in multilingual sites.
• Works with content negotiation: The canonical URL uses server-driven negotiation, while hreflang tags provide explicit crawlable signals.
• x-default tag: Specifies a fallback page for unmatched language/region combinations.