GET — Method Context

Technique Definition

GET is not itself the elicitation technique. It is the primary retrieval method context that carries validator, precondition, and range request modifiers. Under Existence Oracle analysis, GET matters because it is the method under which the broadest set of RFC-defined representation-evaluation outcomes can be elicited without changing resource state.

Primary Headers / Methods

Method

• GET

Common Technique Carriers

• If-None-Match
• If-Modified-Since
• If-Match
• If-Unmodified-Since
• Range
• If-Range

Representation Metadata Commonly Involved

• ETag
• Last-Modified
• Content-Range
• Accept-Ranges

Can Elicit

Primary Differentials

• 304 vs 404
• 206 vs 404
• 416 vs 404

Secondary / Adjacent Outcomes

• 412 vs 404 when GET is combined with precondition headers such as If-Match or If-Unmodified-Since
• 200 fallback branches when range or conditional behavior is ignored or not triggered

Stage Role

Under this taxonomy, GET is the main carrier method for almost every technique on this page set. It is the default method context for retrieval-side existence probing.

Best Use

GET is best used when the goal is to elicit RFC-defined existence leakage without mutating server state.

It is the cleanest general method context for:

• validator-driven 304 behavior
• byte-range-driven 206 and 416 behavior
• controlled precondition testing where non-destructive retrieval is preferred over mutation-oriented methods

Why It Works as an Existence Trigger

GET requests a current selected representation for the target resource. That makes it the natural method under which the server reveals whether a representation exists, whether validators match that representation, and whether byte-range semantics can be applied to it. When a conditional or range branch is observed on GET, the server has necessarily progressed into representation-aware evaluation rather than stopping at simple target absence.

Method Applicability

Validator Retrieval

• GET is a primary context for If-None-Match and If-Modified-Since.
• This is the cleanest route to 304 Not Modified under RFC-defined semantics.

Range Evaluation

• GET is the only RFC-defined method for range handling.
• This makes it the required context for Range and If-Range as elicitation techniques.

Precondition Evaluation

• GET can also carry If-Match and If-Unmodified-Since.
• Those pairings are protocol-valid, but are less central than validator or range use because GET is not primarily a state-changing method.

Non-Destructive Probing

• Among all methods in scope here, GET is the most natural general-purpose probe method because it does not itself seek to modify the selected representation.

Trigger Strength / Normative Level

Strongest GET-Specific Branch

When If-None-Match evaluates false on GET, the origin server MUST respond with 304 Not Modified. This is one of the strongest and cleanest RFC-defined existence-relevant branches available anywhere in the elicitation taxonomy.

Range Behavior

When GET carries a satisfiable Range request and the relevant conditions are met, the server SHOULD send 206 Partial Content. When the requested range is unsatisfiable, the server SHOULD send 416 Range Not Satisfiable. The server may still ignore Range, so these are weaker than the If-None-Match 304 branch.

Precondition Branches

When GET carries If-Match or If-Unmodified-Since and the condition evaluates false, the server MUST NOT perform the method, but the RFC is less rigid about the exact response code than it is for If-None-Match.

Portability Notes

• GET is the most portable method context because all general-purpose servers must support it.
• It is the safest default method for non-destructive probing.
• Its strongest oracle branch comes from If-None-Match, not from plain GET alone.
• GET should not be conflated with generic caching behavior; the existence signal comes from the attached RFC-defined technique.

Detection Notes

1. Use GET as the default method context unless the specific technique requires otherwise.
2. Add exactly one manipulator such as If-None-Match, If-Modified-Since, Range, or If-Range.
3. Compare a known-existing target and a known-nonexistent target.
4. Classify the observed branch by the technique, not by GET alone.
5. Treat plain GET responses without conditional or range modifiers as baseline context, not as the main oracle result.

Relationship to Other Techniques

Versus HEAD

• GET returns the representation content when a content-bearing branch is taken.
• HEAD mirrors many of the same semantics but suppresses message content, making it a narrower method-context analysis.

Versus Range

• GET is the carrier method.
• Range is the actual partial-transfer elicitation technique.

Versus If-None-Match

• GET provides the method context in which the cleanest 304 branch is reached.
• If-None-Match is the real trigger.

Scope & Limitations

• GET alone does not prove existence leakage.
• It does not by itself create a distinctive RFC-defined oracle branch.
• It does not prove that a shared cache is present.
• It does not prove prior storage, freshness lifetime, cache keying, or cache hits.
• The actual existence signal still comes from the attached validator, precondition, or range technique.