- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 Oct 2009 15:53:23 +1100
- To: Jamie Lokier <jamie@shareable.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Jamie (et al), Have you had a chance to have a look at the changes in draft 07 of p6? Specifically, http://trac.tools.ietf.org/wg/httpbis/trac/changeset/607 includes the following text: > 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 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 request, it can only match > another request if it is also absent there. Especially noting the last sentence. Does this address the issue? Cheers, On 25/06/2009, at 4:04 PM, Mark Nottingham wrote: > I haven't seen any comment on this, so my inclination is to > incorporate into -07 and see how it stands in context. I'll leave > the issue open for now, and close once people have a chance to see > that. > > > On 04/06/2009, at 5:06 PM, Mark Nottingham wrote: > >> 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/ >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 6 October 2009 04:53:58 UTC