RE: i107

Mark Nottingham wrote:
> 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.

This interpretation effectively requires implementations to use the same
Accept-* headers (more generally, whatever headers are listed in the Vary
header) for every request for each resource, across methods. For example, if
you put "Accept-Encoding: deflate" in GET requests to fetch resources, then
you need to include the same "Accept-Encoding: deflate" in all your
conditional editing requests (PUT, POST, and DELETE) on that resource
(assuming Vary: Accept-Encoding) in order to ensure that the conditional
request does what it is expected to do.

I don't understand why that restriction is useful and I don't think
conditional requests are universally implemented that way (especially for
editable resources behind mod_deflate-like filters). On the other hand, I am
sure that some servers *do* implement that restriction so my expectations
for how things should work universally are unrealistic. In other words, I
don't think that the specification can be changed to make the undefined case
well-defined, since any additional requirements are going to break existing
servers. 

By the way, does a 304 response mean that a particular variant has not been
modified, or the whole resource has not been modified? I've always assumed
304 Not Modified meant that the resource was unmodified--i.e. all variants
are unmodified. RFC 2616 says "the document has not been modified" but it
isn't clear to me whether "document" means "resource" or "variant."

Regards,
Brian

> 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 17:52:24 UTC