Summary

  • RFC 9111 permits caches to collapse misses into one forward request only when the returned response may be reused for the requests in question.
  • Each waiter still needs its own reuse decision across target, method, Vary fields, authorization and cache-control state.

Consider an explicitly hypothetical edge gateway. Two GET requests for the same URI arrive almost together. One is anonymous; the other carries an Authorization field and expects an account-specific representation. The gateway elects the first request as leader, sends one request upstream and fans the resulting 200 OK out to both waiters. Origin load falls, but the second response decision has disappeared inside the optimization.

RFC 9111 allows request collapsing for a practical reason. When several incoming requests miss at once, a cache can combine them into one forwarded request and reduce load on the origin and network. The permission has a condition: the returned response must be allowed to satisfy the requests in question. If it cannot be used for some or all of them, those requests need to be forwarded, even though that can add latency.

That qualification matters because reuse is not decided by URI resemblance alone. Before a stored response may be reused, the presented target URI must match; the method associated with the stored response must permit reuse; request fields nominated by Vary must match; no-cache conditions must be satisfied; and the response must be fresh, permitted to be served stale, or successfully validated. A collapse changes the number of upstream fetches. It does not erase these per-request conditions.

Vary is one part of that decision. RFC 9110 says it names request fields that might have influenced representation selection and thereby expands the cache key used for a later match. RFC 9111 then defines how nominated fields match, including normalization and the treatment of absent fields. A Vary value containing * always fails to match. Yet Vary does not convert all waiting requests into one request; it supplies evidence for distinguishing them.

Authorization makes the boundary concrete. RFC 9111 says a shared cache must not reuse a cached response to a request containing Authorization for subsequent requests unless an enabling Cache-Control directive is present and its requirements are met. The point is not that collapsed requests are necessarily authenticated. It is that fan-out cannot outrun the controls that would govern ordinary reuse.

The dangerous metric is therefore “origin requests saved” without a corresponding “waiters independently released”. A successful leader fetch proves that one upstream transaction returned a response. It does not prove that every follower shared the same selecting fields, authorization constraints, freshness state or reuse permissions. When these inputs differ, a separate forward is correctness, not inefficiency.

Operators can preserve both capacity and evidence with a collapse-release receipt. This is an editorial control construct proposed here, not an IETF-defined protocol object. It should bind one leader request to every waiter, record the returned response and stored-response identifier, normalize the method and target, compare each nominated field, evaluate authenticated-response and Cache-Control rules, and record either release or a separate forward for each waiter.

The receipt exposes the exact trade-off. Collapse remains a shared-fetch optimization. Response delivery remains an individual decision. A platform can then measure saved upstream work without silently counting an ineligible fan-out as a cache hit.

Sources