HTTP Content Negotiation
HTTP content negotiation is the mechanism by which a client and server agree on the best representation of a resource. Clients send headers such as Accept, Accept-Language, and Accept-Encoding, and the server responds with a matching format, language, or compression.
Technical Architecture & Deep-Dive
A single URL can serve JSON or XML, English or German, gzip or Brotli. The server inspects request headers and returns the most suitable variant, indicating the choice with Content-Type, Content-Language, and Content-Encoding.
Caches must account for negotiation using the Vary header, otherwise a Brotli response might be served to a client that cannot decode it. Edge platforms handle encoding negotiation automatically.
Key Architectural Benefits
Implement HTTP Content Negotiation at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:What does the Vary header do?
Vary tells caches which request headers affect the response, so they store separate variants, for example per Accept-Encoding value.
Related Architecture Concepts
Brotli is a lossless compression algorithm developed by Google that typically compresses text, HTML, and JSON 15 to 25 percent smaller than gzip. Browsers and HTTP clients advertise support with the Accept-Encoding header, and servers or CDNs return compressed responses.
A cache key is the unique identifier a cache uses to store and look up a response. It is typically built from the request URL and may include query parameters, selected headers, or user attributes. Two requests with the same cache key receive the same cached response.
Cache-Control is an HTTP response header that tells browsers, CDNs, and proxies whether and how long a response may be cached. Directives such as max-age, s-maxage, private, no-store, and stale-while-revalidate control freshness and sharing for every cached copy.