If-None-Match

Technique Definition

If-None-Match makes a request conditional on the recipient not finding a current representation whose entity tag matches the supplied validator. Under Existence Oracle analysis, it is the cleanest validator-based trigger for forcing the server to reveal whether a current representation exists and was evaluated.

Primary Headers / Methods

Request Header

• If-None-Match

Representation Metadata It Relies On

• ETag

Primary Method Context

• GET
• HEAD

Secondary Method Context

• Methods other than GET and HEAD can still use If-None-Match, but a false condition leads to 412 Precondition Failed rather than 304 Not Modified.

Can Elicit

Primary Differential

• 304 vs 404

Secondary / Adjacent Outcomes

• 412 vs 404 on non-GET / non-HEAD methods when the condition evaluates false
• 200 vs 404 when a supplied entity tag does not match an existing representation

Stage Role

Under this taxonomy, If-None-Match is primarily the canonical trigger for 304 vs 404.

Best Use

If-None-Match is the cleanest technique when the goal is to ask, in RFC-defined terms, whether any current representation exists without requesting the full representation body.

The strongest canonical form is:

• If-None-Match: *

That form is especially useful because it turns the technique into an existence-oriented validator probe rather than a version-specific validator probe.

Why It Works as an Existence Trigger

For GET and HEAD, a false If-None-Match condition yields 304 Not Modified, which only makes sense after the server has identified and evaluated a current representation. A nonexistent target does not reach that representation-evaluation outcome and instead bottoms out at 404 Not Found.

Method Applicability

GET

• Primary method for this technique.
• Cleanest path to 304 vs 404.

HEAD

• Also primary.
• Same validator logic, but without transferring a response body.
• Important to document explicitly because the technique is still valid even when response-body differences are unavailable.

Other Methods

• Valid at the protocol level, but no longer the cleanest cache-probing-style use case.
• A false condition produces 412, which makes this branch overlap with broader precondition analysis rather than pure validator retrieval.

Trigger Strength / Normative Level

Strong Normative Core

When the If-None-Match condition evaluates false, the RFC-defined response path is strong and explicit:

• 304 Not Modified for GET or HEAD
• 412 Precondition Failed for other methods

Practical Result

This gives If-None-Match a strong normative basis as an elicitation technique because the response code is not merely conventional; it follows directly from the conditional-request rules.

Portability Notes

• Best portability comes from GET / HEAD plus If-None-Match: *.
• Using a fabricated specific ETag is weaker for oracle purposes because a non-match against an existing resource usually yields 200, not 304.
• If-None-Match takes precedence over If-Modified-Since when both are present, so this technique should usually be tested in isolation.
• This technique proves representation 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. Send the same GET or HEAD request to both.
3. Add only one manipulator: If-None-Match: *.
4. Compare outcomes.
5. A 304 on the existing target and 404 on the nonexistent target is the cleanest oracle confirmation for this technique.

Scope & Limitations

• It does not by itself 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 conditional evaluation reached an existing current representation.