parlov docs

Range Elicitation

Range elicitation techniques use the Range request header to force the server into representation-aware evaluation paths that diverge based on target existence.

Implemented

Range elicitation techniques use the Range request header to force the server into representation-aware evaluation paths that diverge based on target existence. The server must resolve the target resource and evaluate the requested byte range against the selected representation before generating a range-specific response.

This family is unique among Cache Probing techniques: it is Safe by definition because RFC 9110 defines range handling only for GET. No mutating method context exists.

This family covers two techniques:

  1. Range (primary) — the direct range-evaluation trigger. Can elicit both 206 (satisfiable range) and 416 (unsatisfiable range) against 404. The only technique that probes both partial-content and range-rejection behavior.
  2. If-Range (refinement) — a validator-gated range gate. Controls whether Range is honored or collapsed into a full response. Does not create a clean standalone differential but proves validator-aware range evaluation occurred.

Risk tier: Safe — GET-only, read-only probing with no state mutation.

Primary differentials: 206 vs 404, 416 vs 404

Secondary outcomes: 200 vs 404 (when the server ignores Range or If-Range collapses to full response)