Negotiation Elicitation
Negotiation elicitation techniques use proactive negotiation request headers to force the server into representation-selection paths that diverge based on target existence.
Negotiation elicitation techniques use proactive negotiation request headers to force the server into representation-selection paths that diverge based on target existence. The server must resolve the target resource and evaluate its candidate representations against the client's stated preferences before generating a negotiation-failure response.
This family covers four techniques, ordered by canonical strength:
Accept(canonical) — media-type negotiation. Cleanest path to406 vs 404. Strongest proactive-negotiation trigger.Accept-Language(secondary) — language negotiation. Valid path to406, but the RFC leans toward fallback over refusal.Accept-Encoding(tertiary) — content-coding negotiation. Structurally valid but often defeated by identity fallback.Accept-Charset(weak / legacy) — charset negotiation. Deprecated in RFC 9110. Included for completeness.
Risk tier: Safe — all four headers apply primarily to GET/HEAD. Reachable on other methods in principle, but the canonical use is read-only probing.
Primary differential: 406 vs 404
Secondary outcomes: 200 vs 404 (when the server disregards the negotiation header and sends a default representation)
If-Range
If-Range makes a range request conditional on a validator — if the selected representation is unchanged, honor the accompanying Range request; otherwise, send the entire current representation.
Accept
Accept lets the client constrain which media types are acceptable in the response — the cleanest proactive-negotiation technique for eliciting 406 vs 404.