How clients say what they can accept
Proactive content negotiation lets a client tell the server which formats,
compression schemes and languages it prefers, and the server picks the best match.
This reference covers the four Accept-family headers, the q-value weighting
syntax they share, and the wildcard precedence rules — plus a parser that sorts
any header by preference.
How it works
Each header is a comma-separated list of values, each optionally carrying a
quality factor with ;q=:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
Accept-Language: en-GB, en;q=0.7, fr;q=0.3
The server scores every value it can produce by the client’s q (default 1),
breaking ties by specificity (text/html > text/* > */*). A value with
q=0 is explicitly refused. The chosen variant is reflected back — in
Content-Type, Content-Encoding or Content-Language — and the response
should carry a matching Vary header so caches key correctly.
Tips and notes
- Default q is
1; only add;q=when you need a non-default preference. q=0is a hard reject, useful for opting out of a specific coding or language.- A response that varies by these headers must send
Varylisting them. Accept-Charsetis effectively dead — assume UTF-8 and ignore it for new APIs.