HEAD — Method Context

Technique Definition

HEAD is not itself the elicitation technique. It is a retrieval-oriented method context that mirrors GET semantics except that the server must not send response content. Under Existence Oracle analysis, HEAD matters because it can carry many of the same conditional request mechanisms as GET, but it suppresses the message body and is weaker for range-centered analysis.

Primary Headers / Methods

Method

• HEAD

Common Technique Carriers

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

Representation Metadata Commonly Involved

• ETag
• Last-Modified
• Content-Length
• Vary

Not a Core Carrier For

• Range
• If-Range

Because RFC 9110 defines range handling only for GET.

Can Elicit

Primary Differential

• 304 vs 404

Secondary / Adjacent Outcomes

• 412 vs 404 when HEAD is combined with precondition headers such as If-Match or If-Unmodified-Since
• Metadata-only confirmation of representation-aware evaluation without transferring a response body

Stage Role

Under this taxonomy, HEAD is a narrower method-context analogue of GET. It is strongest for conditional retrieval analysis, not for range evaluation.

Best Use

HEAD is best used when the goal is to test conditional retrieval behavior while suppressing transfer of the response body.

For Existence Oracle analysis, its cleanest use is:

• validator-driven 304 vs 404 testing via If-None-Match or If-Modified-Since

It can also support precondition testing, but that is secondary.

Why It Works as an Existence Trigger

HEAD is defined as identical to GET except that the server must not send content in the response. That means when a conditional branch such as 304 Not Modified is reached on HEAD, the server has still performed representation-aware evaluation; it has simply omitted the message body. The existence signal therefore comes from the same RFC-defined semantics as GET, but is expressed through headers and status only.

Method Applicability

Conditional Retrieval

• HEAD is explicitly usable with conditional request headers to keep its semantics consistent with GET.
• This makes it valid for validator-driven 304 analysis.

Precondition Evaluation

• HEAD can also carry If-Match and If-Unmodified-Since.
• Those uses are protocol-valid, but they are less central than validator-based conditional retrieval.

Range Evaluation

• HEAD is not the core method context for Range or If-Range.
• RFC 9110 defines range handling only for GET, so HEAD should not be treated as a primary range technique carrier.

Efficiency Context

• HEAD is useful when the tester wants representation metadata and response classification without content transfer.
• The RFC even notes there is often little point in sending a conditional HEAD, because a successful response is around the same size as a 304, but the semantics remain valid.

Trigger Strength / Normative Level

Core Mirror Rule

HEAD is identical to GET except that the server MUST NOT send content in the response. The server SHOULD send the same header fields it would have sent for GET, though it MAY omit fields whose values are determined only while generating content.

Strongest HEAD-Specific Oracle Branch

When If-None-Match evaluates false on HEAD, the origin server MUST respond with 304 Not Modified, just as it must for GET. This makes HEAD a valid carrier for the strongest validator-based existence branch.

Practical Result

HEAD preserves the clean 304 oracle branch, but contributes less to the other technique families because its value is primarily metadata-only mirroring rather than range evaluation.

Portability Notes

• HEAD is highly portable because all general-purpose servers must support it.
• Its strongest value is as a low-transfer mirror of GET for conditional retrieval testing.
• Some response headers may be omitted if they are only known during content generation, so header-level parity with GET is not absolute.
• HEAD should not be used as the primary context for range techniques.
• This method context proves representation-aware conditional evaluation, not that a shared cache exists or that prior responses were stored.

Detection Notes

1. Use HEAD when you want status-plus-metadata evaluation without response content.
2. Add exactly one manipulator such as If-None-Match or If-Modified-Since.
3. Compare a known-existing target and a known-nonexistent target.
4. A 304 / 404 split is the cleanest validator-driven oracle under HEAD.
5. Treat any header differences from GET carefully, since the RFC allows omission of some content-generation-dependent fields.

Relationship to Other Techniques

Versus GET

• HEAD mirrors GET semantics but suppresses content.
• GET is the broader and more central method context.

Versus If-None-Match

• HEAD provides a valid carrier for the clean 304 branch.
• If-None-Match remains the true trigger.

Versus Range

• HEAD should not be treated as the main method context for range evaluation.
• Range belongs under GET.

Scope & Limitations

• HEAD 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.
• It is not the primary method context for Range or If-Range.
• The actual existence signal still comes from the attached conditional or precondition technique.