If-Range

Technique Definition

If-Range makes a range request conditional on a validator. Informally, it means: if the selected representation is unchanged, honor the accompanying Range request; otherwise, ignore Range and send the entire current representation instead. Under Existence Oracle analysis, If-Range is not a primary source of a new differential, but a validator-gated refinement that controls whether range semantics stay active.

Primary Headers / Methods

Request Headers

• If-Range
• Range

Representation Metadata It Relies On

• ETag
• Last-Modified
• Content-Range

Primary Method Context

• GET with Range

Secondary Method Context

• None for RFC-defined use.
• If-Range is only meaningful when paired with Range.

Can Elicit

Primary Differential Role

• Does not define a standalone existence differential in the same clean way as Range, If-None-Match, or If-Match.

Adjacent / Supporting Outcomes

• 206 when the validator matches and the server honors Range
• 200 when the validator does not match and the server ignores Range
• Indirect support for 206 vs 404 where the existing target reaches range evaluation and the nonexistent target bottoms out at 404

Stage Role

Under this taxonomy, If-Range is best treated as a range-gating refinement rather than as the canonical trigger for a separate differential.

Best Use

If-Range is best used when the goal is to test whether a server will continue partial-transfer behavior only if the client's validator still matches the current representation.

For Existence Oracle analysis, it is most useful as a scoped follow-on to Range, because it can show that the server located a representation, evaluated a validator, and then decided whether to preserve or collapse range semantics.

Why It Works as an Existence Trigger

When If-Range is evaluated on an existing target, the server must compare the supplied validator against the current selected representation before deciding whether to honor Range. If the condition is true, the server should process the range request and can return 206 Partial Content. If the condition is false, the recipient must ignore Range, which ordinarily collapses the response into a full-representation 200 OK branch instead of a range-specific result.

That behavior is existence-relevant because it depends on representation-aware validator evaluation, but it is less clean as a standalone oracle because the false branch is not a precondition failure and does not create a sharp RFC-defined status split like 304, 412, or 416.

Method Applicability

GET

• Primary and only meaningful RFC-defined method context.
• If-Range only matters when the request is also a Range request, and range handling is defined only for GET.

HEAD

• Not a valid core If-Range method context.
• Without active Range processing, If-Range has no RFC-defined elicitation role.

Other Methods

• Not meaningful for this technique under RFC 9110.
• If-Range should not be treated as a general conditional-request trigger outside GET + Range.

Trigger Strength / Normative Level

Client-Side Constraints

• A client MUST NOT send If-Range without Range.
• A client MUST NOT send a weak entity tag in If-Range.
• A client MUST NOT send an HTTP-date unless it has no entity tag and that date is a strong validator.

Server / Recipient Behavior

• A server that receives If-Range on a range request MUST evaluate the condition before performing the method.
• If the condition evaluates false, the recipient MUST ignore the Range header field.
• If the condition evaluates true, the recipient SHOULD process the Range request as requested.

Practical Result

This gives If-Range strong normative footing for validator evaluation, but weaker oracle cleanliness than the other techniques because its false branch usually becomes 200 rather than a dedicated failure code.

Validator Forms

Entity-Tag Form

• Must use exact strong comparison against the current ETag.
• Weak entity tags are not allowed here.

HTTP-Date Form

• Uses exact match against Last-Modified, not the "earlier than or equal to" logic used by If-Unmodified-Since.
• This makes the date form stricter and often less forgiving.

Consequence

If-Range is a precise range-gating validator, not a general freshness check.

Portability Notes

• If-Range is most portable when used with a strong ETag.
• The false branch commonly becomes 200 OK, which is less distinctive for existence work than 304, 412, or 416.
• Because If-Range depends on Range, any server behavior that ignores Range also weakens this technique.
• This technique proves validator-aware range gating, not that a shared cache exists or that prior responses were stored.

Detection Notes

1. Establish a known-existing target and a known-nonexistent target.
2. Use GET with both Range and If-Range.
3. Supply a validator chosen to test either the matching branch or the non-matching branch.
4. Compare whether the existing target preserves 206 behavior or collapses into a full-response branch.
5. Treat this as a supporting technique, not the cleanest primary existence oracle.

Relationship to Other Techniques

Versus Range

• Range is the primary range-evaluation trigger.
• If-Range is the refinement that decides whether Range survives validator checking.

Versus If-Match

• If-Match blocks the method on a false condition and can lead to 412.
• If-Range does not block the method that way; it falls back by disabling Range.

Versus If-Unmodified-Since

• If-Unmodified-Since uses precondition semantics.
• If-Range uses range-gating semantics and exact validator matching.

Scope & Limitations

• It does not prove that a shared cache is present.
• It does not prove that a prior response was stored in an intermediary.
• It does not prove freshness lifetime, cache keying, or cache hits.
• It does not create a clean standalone status differential on its own.
• It only proves that RFC-defined validator-gated range handling was evaluated when the server actually applies it.