W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Feb 2008 12:56:58 +1100
Message-Id: <F6E94A10-A5A7-423E-B679-F6B6EDF5F865@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

Issue referenced at the bottom is <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/107 

On 13/02/2008, at 5:25 PM, Mark Nottingham wrote:

>> 14.25 (If-Modified-Since)
>>> The If-Modified-Since request-header field is used with a method  
>>> to make it conditional: if the requested variant has not been  
>>> modified since the time specified in this field, an entity will  
>>> not be returned from the server [...]
>>> A GET method with an If-Modified-Since header and no Range header  
>>> requests that the identified entity be transferred only if it has  
>>> been modified since the date given by the If-Modified-Since  
>>> header. The algorithm for determining this includes the following  
>>> cases: a) If the request would normally result in anything other  
>>> than a 200 (OK) status, or if the passed If-Modified-Since date is  
>>> invalid, the response is exactly the same as for a normal GET. A  
>>> date which is later than the server's current time is invalid. b)  
>>> If the variant has been modified since the If-Modified-Since date,  
>>> the response is exactly the same as for a normal GET. c) If the  
>>> variant has not been modified since a valid If- Modified-Since  
>>> date, the server SHOULD return a 304 (Not Modified) response.
>> 14.28 (If-Unmodified-Since)
>>> If the requested variant has been modified since the specified  
>>> time, the server MUST NOT perform the requested operation, and  
>>> MUST return a 412 (Precondition Failed).
>> 14.29 (Last-Modified)
>>> The Last-Modified entity-header field indicates the date and time  
>>> at which the origin server believes the variant was last modified.
>> Interestingly, Last-Modified validation is defined in terms of  
>> 'requested variant', whereas ETag validation (If-Match, If-None- 
>> Match) seem to go out of their way to say that *any* entity that  
>> meets the conditional can be returned, and never mind the selecting  
>> headers. I'd be interested in hearing if any implementations  
>> actually do that, and unless some are found, I'd suggest we need to  
>> tighten up how ETag validation is defined..
> PROPOSAL: s/requested variant/selected representation/g; s/variant/ 
> selected representation/g
> And, add an issue about the implied divergence in the ETag and LM  
> validation models.

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 February 2008 01:57:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC