RE: i107

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

Received on Monday, 28 July 2008 16:48:08 UTC