Dated report · 22 Oct 2026 · RFC 9111 validation
Selecting stored responses after a 304
RFC 9111 §4.3.4 first limits consideration to responses that could have been chosen for the request, then selects stored entries with a strong, weak, or absent validator.
Practical rule
Build the initial set from request-compatible stored responses, leaving out only the final freshness/stale/validation gate. Then take the first applicable validator branch: matching strong validators select all matching entries; without a strong validator, matching weak validators select only the most recent; with no validator, only one validator-less entry in a singleton candidate set qualifies. The 304 updates metadata—it does not carry replacement representation bytes.
Candidate qualification and validator selection are separate steps; a validator cannot make a URI, method, or request variant match.
- Qualify
Target URI · reusable method · matchingVaryfields ·no-cachevalidation condition - Strong?
Update all initial-set matches; if no strong match, update none - Else weak?
With no strong validators, update the most recent weak match byDate - Else none?
A singleton validator-less entry is the only match
1. Form the initial set before comparing validators
RFC 9111 §4.3.4 says the initial set contains stored responses that could have been chosen for the request under §4, except the last requirement that a response be fresh, allowed stale, or already validated. Apply the same target-URI match, method-reuse rule, request-header matching nominated by Vary, and the no-cache condition. As a result, an otherwise eligible stale response remains available for a validation update, but a different target URI, incompatible method, or nonmatching variant is not a candidate. A stored Vary: * response never matches. RFC 9111 §4, §4.1, §4.3.4.
2. Use the first applicable validator branch
Strong validators in the 304
Each strong validator identifies a selected representation. All initial-set responses with one of those same strong validators are selected, so more than one entry can be updated. If no initial-set response shares a strong validator, the cache MUST NOT use the 304 to update any stored response; it does not fall through to weak matching.
No strong validator, but weak matches
When the 304 has no strong validator and has one or more weak validators corresponding to initial-set entries, select the most recent matching stored response. RFC 9111 §4 determines “most recent” using Date, not every weak match.
No validator of any kind
The 304 can identify a response only when the initial set has exactly one entry and that stored response also has no validator. One validator-bearing entry does not qualify, and multiple validator-less candidates do not qualify.
For the compact example below, an unprefixed ETag is strong by default; W/ marks a weak ETag. RFC 9110 §8.8.2.2 says Last-Modified is implicitly weak when used as a validator unless the specified conditions let it be deduced as strong. RFC 9110 §8.8.1, §8.8.2.2, §8.8.3.
A synthetic selection example
Assume a cache is validating GET /manual with the same request headers used to store each entry, and each listed response meets the target URI, method, and Vary checks. The four are all stale; freshness does not exclude them from the §4.3.4 initial set. Date is shown only to resolve “most recent.”
| Stored entry | Stored ETag | Date |
|---|---|---|
| A | "rev-7" (strong) | 10:00 |
| B | "rev-7" (strong) | 10:02 |
| C | W/"group-2" (weak) | 10:03 |
| D | W/"group-1" (weak) | 10:01 |
- Strong case: a 304 with
ETag: "rev-7"andCache-Control: max-age=600selects A and B, not C or D. The freshness field updates metadata for both selected entries under §3.2. - Weak case: a different 304 with only
ETag: W/"group-1"selects D because it is the only weak match. If A and B instead both hadW/"group-1", only the more recent one byDatewould be selected. - No-validator case: a 304 without any validator selects none from this four-entry set. A separate initial set containing exactly one validator-less response would meet the exception.
These are alternative synthetic outcomes, not evidence that an implementation stores duplicate entries or would produce this exact set.
3. Freshen selected headers; keep the stored body
For each selected response, RFC 9111 §4.3.4 requires the cache to update stored header fields with fields provided in the 304, following §3.2. That section describes adding provided fields and replacing existing values, subject to excluded or automatically processed fields, fields on which the stored response depends, and Content-Length. Special handling can apply to a cache storing a processed representation when an update would make it inconsistent.
RFC 9110 §15.4.5 says a 304 response is terminated at the end of its header section and cannot contain content or trailers. Its purpose is to minimize transfer when a recipient has a cached representation; required 304 header fields include Content-Location, Date, ETag, Vary, Cache-Control, and Expires when they would have appeared on the corresponding 200. The cache/client reuses the already stored representation body; the 304 contains metadata, not replacement bytes. RFC 9111 §3.1, §3.2, §4.3.3, RFC 9110 §15.4.5.
Evidence boundary
Normative finding: the cited RFCs specify the candidate set, validator precedence, narrow no-validator exception, and metadata update rule. Inference limit: observing a bare 304 does not establish which hop supplied it, which implementation-specific stored entry was updated, whether a page visibly changed, or whether missing bytes were restored. Those conclusions need request/response traces and/or evidence about the implementation. No such test evidence was available here.
Sources and limitations
- RFC 9111 §3.1, §3.2, §4, §4.1, §4.3.3, and §4.3.4: stored-field updates, reuse eligibility,
Vary, validation responses, and freshening. - RFC 9110 §8.8.1, §8.8.2.2, and §8.8.3: validator strength,
Last-Modifiedcomparison, and entity tags. - RFC 9110 §15.4.5: 304 semantics, required metadata, and no-content/no-trailer rule.
- RFC 9111 errata, checked 22 Oct 2026: the listed item is a rejected erratum in §4.3.2, not an accepted correction to the sections used here.