Validator Elicitation
Validator elicitation techniques use conditional request headers to force the server into representation evaluation paths that diverge based on target existence.
Validator elicitation techniques use conditional request headers to force the server into representation evaluation paths that diverge based on target existence. The server must resolve the target resource and evaluate its current state against the supplied validator before generating a conditional response.
This family covers two techniques, ordered by normative strength:
If-None-Match(primary) — entity-tag-based validator. MUST-level path to 304 on GET/HEAD. Strongest canonical trigger.If-Modified-Since(secondary) — date-based validator. SHOULD-level path to 304 on GET/HEAD. Weaker normative footing, useful as fallback when ETags are absent.
Risk tier: Both techniques are Safe when used on GET/HEAD — read-only probing with no state mutation. If-None-Match on non-GET/HEAD methods enters mutating territory and produces 412 instead of 304.
Primary differential: 304 vs 404
Secondary differential: 412 vs 404 (via If-None-Match on non-GET/HEAD), 200 vs 404 (when the condition evaluates true)
406 vs 404 — Negotiation Failure
A request with unsatisfiable proactive negotiation headers reaches negotiation evaluation for an existing target.
If-None-Match
If-None-Match makes a request conditional on the recipient not finding a current representation whose entity tag matches the supplied validator.