Re: i37: Vary and non-existant headers

Presumed OK, closing. If there are concerns, please raise them on-list.


On 06/10/2009, at 3:53 PM, Mark Nottingham wrote:

> 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/
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 14 October 2009 09:34:08 UTC