Content Negotiation

The client sends Accept-Encoding listing codings it can decode, such as gzip, br, zstd. The server may compress the body with one of them and must say which in Content-Encoding. The client decompresses before parsing. Uncompressed is called identity.

q is a relative preference weight from 0 to 1 (three decimals max). Omitted means q=1, the strongest preference; q=0 means unacceptable. So in that header application/json (q=1) is preferred over text/html (0.8). Header order carries no priority.

406 is about the response: the server cannot produce any representation matching the request's Accept headers. 415 is about the request body: the server cannot process the Content-Type (or Content-Encoding) the client sent. Response side versus request side.

The server routes a body by its declared Content-Type, not by sniffing the bytes. With no Content-Type or the wrong one, there is no parser to hand it to, so it returns 415 — ideally with an Accept-Post header naming the media types it accepts.

Accept-Language lists language tags such as en-GB or fr that a client prefers for the response; the server picks a translation and reports it in Content-Language. Accept-Charset is obsolete because everything is UTF-8 now, so browsers stopped sending it.

They are media ranges of decreasing specificity: an exact type, any subtype of text, then anything. A server matches its available representations against them and the most specific matching range wins, so an HTML representation is preferred here.

gzip is the universal baseline — modest ratio, fast, supported everywhere. Brotli compresses text best, especially precompressed at high levels, but is slow to compress at high settings. zstd compresses near-Brotli quality far faster, making it good for dynamic responses; browser support is the newest.

Each candidate takes the weight of the most specific matching entry, not the highest or the first. Precedence: exact type/subtype with parameters, then type/subtype, then type/*, then /. So text/html scores 0.7 and text/plain scores 0.5; text/html wins.

They are media types in the vendor registration tree (vnd.) naming an organisation's own format, usually with a structured suffix like +json. A client asks for one in Accept, e.g. application/vnd.example.v2+json, and the server returns that variant and echoes it in Content-Type.

Content-Encoding is end-to-end: it transforms the representation itself, so only the final recipient decodes it and caches store it encoded. Transfer-Encoding is hop-by-hop framing for one connection — chunked is its only real use — and it does not exist in HTTP/2 or HTTP/3.

Build both a .br and .gz copy beside each asset. The server checks Accept-Encoding, serves the matching file with the original Content-Type, the right Content-Encoding, Vary: Accept-Encoding, a distinct ETag per encoding, and falls back to the uncompressed file.

Most servers ignore an unsatisfiable Accept header and send their default representation, because a 406 is usually less useful than a body the client can inspect and because Accept headers are frequently wrong or over-narrow. 406 is reserved for genuinely strict negotiation.

q=0 means explicitly unacceptable — 'identity;q=0' forbids an uncompressed body. Each Accept-* header is an independent axis; the server scores each representation per axis, combines with fixed axis priority or multiplication plus its own quality factors, and must emit Vary listing every header it negotiated on.

Capture the exact Accept, Accept-Language and Accept-Encoding headers the server actually received, compare them with the representations the server can produce, and find what changed — usually a proxy rewriting Accept or a removed serialiser. Fix by restoring the representation or relaxing to a default.

Compress text-like types above a size threshold, never already-compressed media; precompress static assets at maximum level and use a fast coding for dynamic ones; do it in exactly one layer; and exclude responses that mix secrets with attacker-influenced input.