Range

Technique Definition

Range alters a GET request so the client asks for only one or more subranges of the selected representation instead of the entire representation. Under Existence Oracle analysis, it is the canonical trigger for forcing the server to evaluate whether a current representation exists, whether the requested range is satisfiable against it, and whether partial transfer semantics apply.

Primary Headers / Methods

Request Header

• Range

Representation Metadata It Relies On

• Content-Range
• Accept-Ranges

Primary Method Context

• GET

Secondary Method Context

• None for RFC-defined range handling.
• For this specification, GET is the only method for which range handling is defined.

Can Elicit

Primary Differentials

• 206 vs 404
• 416 vs 404

Secondary / Adjacent Outcomes

• 200 vs 404 when the server ignores the Range header instead of honoring it
• Partial-versus-full representation behavior that confirms evaluation occurred, even when the exact response code is not the strongest portable branch

Stage Role

Under this taxonomy, Range is the direct trigger for both range differentials: satisfiable-range evaluation and unsatisfiable-range evaluation.

Best Use

Range is best used when the goal is to force the server to reveal whether it located a current representation and evaluated byte-range semantics against it.

For Existence Oracle analysis, the two cleanest branches are:

• a deliberately satisfiable byte range to target 206 vs 404
• a deliberately unsatisfiable byte range to target 416 vs 404

This makes Range the only technique that can directly probe both partial-content and range-rejection behavior.

Why It Works as an Existence Trigger

A 206 Partial Content response shows that the server found a selected representation and constructed a partial response from it. A 416 Range Not Satisfiable response shows that the server found a selected representation and rejected the requested range against that representation rather than failing at resource lookup. In both cases, the server has progressed beyond simple target lookup and into representation-aware evaluation.

Method Applicability

GET

• Primary and only RFC-defined method context for Range handling.
• The RFC explicitly defines range handling here.

HEAD

• Not a valid RFC-defined Range method context.
• A server must ignore Range where range handling is not defined, and RFC 9110 defines it only for GET.
• Any HEAD-specific quirks belong under method applicability analysis, not as core Range behavior.

PUT / PATCH / DELETE / Other Methods

• Not valid RFC-defined range contexts.
• Range should be ignored rather than treated as an elicitation mechanism for those methods.

Trigger Strength / Normative Level

Strong Method Constraint

When a server receives Range on a method for which range handling is not defined, it MUST ignore that header field. For RFC 9110, GET is the only defined method context.

Satisfiable Branch

If the preconditions are true, the target supports Range, the range unit is supported, and the requested range is satisfiable with respect to the selected representation, the server SHOULD send 206 Partial Content.

Unsatisfiable Branch

If those conditions otherwise hold but the requested range is unsupported or unsatisfiable with respect to the selected representation, the server SHOULD send 416 Range Not Satisfiable.

Practical Result

This gives Range a strong representation-evaluation basis, but weaker response-code rigidity than If-None-Match, because the RFC still allows the server to ignore Range and return a non-range response instead.

Portability Notes

• Byte ranges are the most portable form and should be the canonical example.
• Accept-Ranges can strengthen interpretation, but a client may still send Range even if it was not advertised beforehand.
• The server may ignore Range, which weakens portability of the response-code branch even when the underlying representation exists.
• Unsatisfiable-range testing can disclose representation-length information through Content-Range.
• This technique proves origin-side range 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 GET only.
3. Add exactly one manipulator: a satisfiable or unsatisfiable Range header.
4. Compare outcomes.
5. A 206 / 404 split is the cleanest satisfiable-range oracle.
6. A 416 / 404 split is the cleanest unsatisfiable-range oracle.
7. If the existing target returns 200, record that the server may have ignored Range rather than concluding the technique is invalid.

Relationship to Other Techniques

Versus If-Range

• Range is the direct range-evaluation mechanism.
• If-Range is the validator-gated refinement that decides whether Range should be honored or collapsed into a full response.

Versus GET

• GET is the carrier method context.
• Range is the actual elicitation technique that alters GET semantics.

Versus HEAD

• HEAD is a method-applicability topic, not a core range trigger.
• It should not be treated as equivalent to GET for this technique.

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 range handling reached an existing selected representation when the range response branch is observed.