Re: i107

14.26;

> If any of the entity tags match the entity tag of the entity that  
> would have been returned in the response to a similar GET request  
> (without the If-None-Match header) on that resource, or if "*" is  
> given and any current entity exists for that resource, then the  
> server MUST NOT perform the requested method, unless required to do  
> so because the resource's modification date fails to match that  
> supplied in an If-Modified-Since header field in the request.  
> Instead, if the request method was GET or HEAD, the server SHOULD  
> respond with a 304 (Not Modified) response, including the cache-  
> related header fields (particularly ETag) of one of the entities  
> that matched. For all other request methods, the server MUST respond  
> with a status of 412 (Precondition Failed).
While this doesn't specifically preclude sending 304 if it doesn't  
match, the semantics of doing so aren't defined, and the intent seems  
pretty clear here.


On 28/07/2008, at 5:47 PM, Brian Smith wrote:

>
> Mark Nottingham wrote:
>> On 28/02/2008, at 5:53 AM, Brian Smith wrote:
>>> (a) GET http://example.org/a HTTP/1.1
>>>   If-None-Match: 1
>>>   Accept-Encoding: deflate
>>>
>>>   HTTP/1.1 304 Not Modified
>>>   ETag: 2
>>>   Vary: Accept-Encoding
>>
>> That's utterly confusing. The client asked to validate etag
>> "1" and you told them that it wasn't modified, but returned
>> an updated ETag and didn't say whether or not the entity is encoded.
>
> I read section 10.3.5 as saying that the ETag returned must be the  
> same one
> as would be returned in a 200 response to the same request. It seems  
> to me
> that if a 200 response could return a different ETag then the 304  
> response
> should also be able to.
>
> The response doesn't say whether or not the entity is encoded  
> because 10.3.5
> says "the response SHOULD NOT include other entity-headers" or "the  
> response
> MUST NOT include other entity-headers" depending on whether a strong  
> or weak
> validator is being used.
>
> The main point of the examples is to point out that "304 Not  
> Modified" is an
> appropriate response, even though a 200 response would have returned a
> representation with a different ETag from the one supplied in the
> conditional request header. Which ETag should be returned is a  
> related, but
> different issue.
>
>> 13.3.4:
>>> An HTTP/1.1 origin server, upon receiving a conditional
>> request that
>>> includes both a Last-Modified date (e.g., in an
>> If-Modified-Since or
>>> If-Unmodified-Since header field) and one or more entity
>> tags (e.g.,
>>> in an If-Match, If-None-Match, or If-Range header field) as cache
>>> validators, MUST NOT return a response status of 304 (Not Modified)
>>> unless doing so is consistent with all of the conditional header
>>> fields in the request.
>
> That doesn't apply here since none of my example requests mixed
> last-modified dates and etags.
>
> Cheers,
> Brian
>
>


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

Received on Tuesday, 29 July 2008 07:11:51 UTC