- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Jun 2009 17:06:46 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
I think the right way to fix this is to move the language about validation into section 2.4 (validation model) and carefully updating that and section 2.7 (combining responses) to indicate how validation affects the response, whether or not there are selecting headers. This requires some non-trivial changes to the text, but we've already done that, and I think the result is worth it... Note that 2.4 already says: > When a stored response includes one or more validators, such as the > field values of an ETag or Last-Modified header field, then a > validating request SHOULD be made conditional to those field values. Proposal for updated section 2.4: """ 2.4. Validation Model Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating" or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when a stored response is valid. When a cache has one or more stored responses for a URI, but cannot serve any of them (see section 2.2), it can use the conditional request mechanism (part 4) in the forwarded request to select a valid stored response to be used, and update it. When sending such a conditional request, the cache SHOULD add an If- Modified-Since header whose value is that of the Last-Modified header from the selected (see section 2.6) stored response, if present. Additionally, the cache SHOULD add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for that URI (see section 2.6), if present. However, if any of the stored responses contains only partial content, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored response. A 304 (Not Modified) response status code indicates that a stored response should be updated and used to satisfy the request; see Section 2.7. A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. [[anchor8: Should there be a requirement here?]] If a cache receives a 5xx response while attempting to validate a response, it MAY either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it MAY return a stale stored response if allowed (see Section 2.3.3). If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that of the existing response, the existing response SHOULD NOT be returned in response to future requests and SHOULD be deleted from the cache.[[anchor13: DISCUSS: Not sure if this is necessary.]] """ Proposal for updated section 2.6: """ 2.6. Caching Negotiated Responses When a cache receives a request that can be satisfied by a stored response with a Vary header field (Section 3.5), it MUST NOT use that response unless all of the selecting request-headers nominated by the Vary header match in both the original request (i.e., that associated with the stored response), and the presented request. The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space [[anchor11: [ref]]] at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in Section 4.2 of [Part1]. If a header field is absent from a a request, it can only match another request if it is also absent there. A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted by the origin server. If no stored response matches, the cache MAY forward the presented request to the origin server as a conditional request; see Section 2.4. """ Proposal for updated section 2.7 (there's some duplication with p5- range section 4 that we need to take care of, btw): """ 2.7. Combining Responses When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (collectively, the "new" response), it needs to update the stored response with the new one, so that the updated response can be used to satisfy the request. If the new response contains an ETag, it identifies the stored response to use. [[ note: may need language about Content-Location here ]] If the status code is 206 (partial content), both the stored and new responses MUST have ETags, and those ETags MUST match using the strong comparison function (see Section 4 of [Part4]). Otherwise, the responses MUST NOT be combined. The stored response headers are used as those of the updated response, except that o Any stored Warning headers with warn-code 1xx (see Section 3.6) MUST be deleted from the stored response and the updated response. o Any stored Warning headers with warn-code 2xx MUST be retained in the stored response and the updated response. o Any headers provided in the new response MUST replace the corresponding headers from the stored response. If a header field-name in the new response matches more than one header in the stored response, all such old headers MUST be replaced. The updated response can [[requirement?]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body MAY be stored. [[anchor14: ISSUE: discuss how to handle HEAD updates]] """ On 08/05/2009, at 7:29 AM, Julian Reschke wrote: > Roy T. Fielding wrote: >> On May 7, 2009, at 12:43 PM, Julian Reschke wrote: >>> Brian Smith wrote: >>>> Julian Reschke wrote: >>>>> "When a cache receives a request that can be satisfied by a stored >>>>> response that includes a Vary header field (Section 3.5), it >>>>> MUST NOT >>>>> use that response unless all of the selecting request-headers >>>>> nominated >>>>> by the *stored* Vary header match in both the original request >>>>> associated with the stored response, and the presented request." >>>> This is wrong, but not for the reason Jamie stated. >>>> Consider this: >>>> 1. Client requests "GET /foo" >>>> 2. Cache forwards the request to the server "GET /foo" with >>>> an If-None-Match: "A", "B", "C" >>>> 3. Server returns "304 Not Modified" with ETag "A". >>>> According to the statement above, the cache could only return the >>>> cached >>>> response with ETag "A" if the Vary'd headers match; otherwise, it >>>> couldn't >>>> return any response at all. However, the cache must be able to >>>> return the >>>> response with ETag "A" regardless of whether the Vary'd headers >>>> match. >>> >>> Why? >>> >>> What you describe sounds like a bug. If the selecting headers that >>> resulted in the response with entity tag "A" had a "Accept- >>> Encoding: gzip", then the response can't be used for a request >>> without "Accept-Encoding", even if it may be fresh. >> Because the origin server just told the cache to deliver "A" in (3). >> The origin server is authoritative. >> We've had this discussion before. > > Right, sorry. > > So the text is only needs to consider the case where the origin > server gives its ok. > > ""When a cache receives a request that can be satisfied by a stored > response that includes a Vary header field (Section 3.5), it MUST NOT > use that response unless all of the selecting request-headers > nominated > by the *stored* Vary header match in both the original request > associated with the stored response, and the presented request, *or > after validating with the origin server*". > > ? > > BR, Julian > > > > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 4 June 2009 07:07:28 UTC