If-Match

Technique Definition

If-Match makes a request conditional on the origin server finding a current representation whose entity tag strongly matches one of the supplied validators, or on the existence of any current representation when the wildcard form is used. Under Existence Oracle analysis, it is the canonical ETag-based precondition trigger.

Primary Headers / Methods

Request Header

• If-Match

Representation Metadata It Relies On

• ETag

Primary Method Context

• PUT
• PATCH
• DELETE
• Other methods that involve selection or modification of a representation

Secondary Method Context

• Can be used with GET or HEAD, but that is not the primary oracle use case here.

Can Elicit

Primary Differential

• 412 vs 404

Secondary / Adjacent Outcomes

• 2xx vs 404 when If-Match: * is used and the resource exists, depending on method semantics and whether the method succeeds
• Occasionally 2xx instead of 412 if the state-changing request appears to have already been applied, which the RFC permits as an alternative branch

Stage Role

Under this taxonomy, If-Match is the cleanest trigger for the 412 vs 404 differential.

Best Use

If-Match is best used when the goal is to force the server to prove that a current representation exists before allowing a state-changing operation to proceed.

For Existence Oracle analysis, the cleanest branch is usually:

• a deliberately false If-Match condition against an existing target

That makes the existing branch terminate at precondition evaluation instead of succeeding and changing state.

Why It Works as an Existence Trigger

A false If-Match evaluation shows that the origin server got far enough to locate the current representation and compare its current entity tag against the supplied condition. A nonexistent target does not reach that comparison outcome and instead bottoms out at 404 Not Found.

Method Applicability

PUT

• Primary method context.
• Especially useful where PUT might otherwise create or replace a representation.

PATCH

• Primary method context.
• Useful when partial modification is gated on the current entity tag.

DELETE

• Primary method context.
• Useful where deletion is conditioned on the current representation matching the client's expectation.

GET / HEAD

• Protocol-valid, but not the main use here.
• The practical oracle value is weaker because these methods are more naturally associated with validator retrieval than with lost-update prevention.

Trigger Strength / Normative Level

Strong Normative Core

When an origin server receives a request with If-Match, it MUST evaluate the condition before performing the method.

If the condition evaluates false:

• the server MUST NOT perform the requested method
• the server MAY indicate failure with 412 Precondition Failed

Practical Result

This gives If-Match a strong precondition-evaluation basis, but the response-code branch is slightly less rigid than If-None-Match because the RFC uses MAY for indicating failure with 412, rather than a universal MUST to emit that exact code.

Wildcard Form

If-Match: *

• The wildcard form is true only if the origin server has a current representation for the target resource.
• This makes it highly relevant to existence analysis.
• However, for oracle work it is often less clean than a deliberately false specific validator because success can let the method proceed into mutation or deletion behavior.

Portability Notes

• Best portability for a non-destructive existence proof comes from sending a deliberately false specific validator so the existing-resource branch terminates before mutation.
• If-Match uses strong comparison semantics, which makes weak validators non-matching for this purpose.
• The wildcard form is existence-sensitive, but can produce a success path rather than a failure path, which is less clean for oracle classification.
• This technique proves origin-side precondition evaluation, not that any intermediary cache stored or served the response.

Detection Notes

1. Establish a known-existing target and a known-nonexistent target.
2. Use a method context where If-Match meaningfully applies, such as PUT, PATCH, or DELETE.
3. Add only one manipulator: an If-Match value designed to evaluate false for the existing target.
4. Compare outcomes.
5. A 412 on the existing target and 404 on the nonexistent target is the cleanest oracle confirmation for this technique.

Relationship to Other Techniques

Versus If-None-Match

• If-None-Match is the cleaner validator-retrieval technique.
• If-Match is the cleaner state-protection / precondition technique.

Versus If-Unmodified-Since

• If-Match is the stronger ETag-based precondition route.
• If-Unmodified-Since is the date-based analogue, generally weaker and coarser.

Scope & Limitations

• It does not prove that a shared cache is present.
• It does not prove that a prior response was stored.
• It does not prove anything about freshness lifetime, cache keying, or cache hits.
• It only proves that RFC-defined precondition evaluation reached an existing current representation.