Cache Probing

Definition

Cache Probing exploits the gap between representation-aware protocol semantics and bare resource lookup. RFC 9110 defines a class of responses — conditional responses (304), precondition failures (412), partial content (206), range rejections (416), and negotiation failures (406) — that presuppose the server has resolved the target resource and evaluated its state, representation, or negotiation dimensions before responding.

A nonexistent resource never reaches these evaluation paths. It terminates at 404 Not Found before the server enters conditional, range, or negotiation logic. The differential between a representation-aware response and a lookup failure is the oracle.

Unlike Status Code Differentials, which observe any status code divergence across resource IDs, Cache Probing vectors are grounded in specific RFC 9110 mechanisms where the protocol requires or permits the server to evaluate target state before generating the response. The signal is not "cache behavior" in the deployment sense — it is that the server advanced into representation-level evaluation rather than stopping at resource lookup.

Why It Matters

Each Cache Probing vector carries a built-in proof of evaluation depth:

• 304 means the server evaluated a validator against the selected representation and found it matched — a conditional retrieval that would have produced 200 if the condition were false.
• 412 means the server tested one or more preconditions against target state and found them false — state-aware evaluation, not mere lookup.
• 206 means the server successfully fulfilled a range request against the selected representation — partial transfer of a resource that exists.
• 416 means the server evaluated a range against the selected representation and rejected it as unsatisfiable — the resource was found, but the range was invalid for its size.
• 406 means the server treated the target as a resource with candidate representations and found none acceptable under the request's negotiation constraints.

In every case, 404 is the contrast: the server did not find a current representation for the target resource, or is not willing to disclose that one exists. The evaluation-depth gap between these responses and 404 is what makes Cache Probing a reliable oracle class.

How It Works

The general pattern across all Cache Probing vectors:

1. Client sends a request that triggers representation-aware evaluation — conditional headers (If-None-Match, If-Match, If-Modified-Since, If-Unmodified-Since), range headers (Range), or negotiation headers (Accept, Accept-Language).
2. Existing target: Server resolves the resource, identifies the selected representation (or candidate representations), evaluates the request against that state, and returns a representation-aware response (304, 412, 206, 416, or 406).
3. Nonexistent target: Server fails at resource lookup and returns 404 before reaching any evaluation path.

The oracle is the status code split. The server cannot produce a representation-aware response without first resolving the target — so any non-404 response from the evaluation path confirms existence.

Vectors

Method Applicability

Scope & Boundaries

What Cache Probing proves:

• The server resolved the target resource before generating the response
• The server entered representation-aware evaluation (conditional, range, or negotiation) rather than stopping at lookup
• The status code differential between evaluation-path responses and 404 confirms existence

What Cache Probing does not prove:

• It does not prove the representation is accessible to the requester in a normal retrieval path
• It does not prove the resource is cacheable in any deployment sense
• It does not distinguish origin-server evaluation from compliant intermediary evaluation
• It does not defeat RFC-sanctioned 404 normalization where the server intentionally hides existence
• 404 is semantically overloaded — per RFC 9110, it can mean either absence or intentional non-disclosure
• Absence of a representation-aware response does not prove absence of the oracle — servers MAY ignore conditional, range, or negotiation headers

Normative strength varies across vectors:

• Strongest: 304 via If-None-Match (MUST) and 412 via If-None-Match on non-GET/HEAD (MUST)
• Moderate: 304 via If-Modified-Since (SHOULD), 206 and 416 via Range (SHOULD)
• Weakest: 406 via proactive negotiation (permitted, not mandated)

Elicitation Techniques