Precondition Elicitation

Precondition elicitation techniques use state-protection conditional headers to force the server into precondition evaluation paths that diverge based on target existence. The server must resolve the target resource and evaluate its current state against the supplied precondition before rejecting the request.

Unlike Validator Elicitation (which targets the retrieval path via 304), Precondition Elicitation targets the state-changing path via 412 Precondition Failed. The server proves existence by reaching precondition logic rather than bottoming out at resource lookup.

This family covers two techniques, ordered by normative strength:

1. If-Match (primary) — ETag-based precondition. MUST evaluate before performing the method. Strongest canonical trigger.
2. If-Unmodified-Since (secondary) — date-based precondition. Same MUST-NOT-perform rule, but coarser validator. Useful as fallback when ETags are absent.

Risk tier: Both techniques are primarily MethodDestructive — they apply to PUT, PATCH, DELETE. A deliberately false precondition prevents the method from executing, but the request itself targets a mutating method. Protocol-valid on GET/HEAD but that is not the primary use case.

Primary differential: 412 vs 404

Secondary differential: 2xx vs 404 (when the precondition passes and the method succeeds)