Some RFC 2616 questions

[Wilfredo Sánchez Vega <ws...@wsanchez.net>]

   The spec for If-{None-}Match and If-{Un}Modified-Since is driving  
me batty.

   The biggest item has to do with having to know the response code  
for the request without processing the request.  Specifically, 14.24  
(If-Match) and the others have a requirement like:

         If the request would, without the If-Match header field,  
result in
         anything other than a 2xx status, then the If-Match header  
MUST be
         ignored.

   This implies that we have to attempt the request, check the  
status, and act on the If-Match header only if the request resulted  
in an non-error status.  That seems rather expensive for the server.   
For example, if we have a GET request that recomputes uncached data  
or something like that.

   Furthermore, for many operations, such as PUT, COPY, MOVE and  
DELETE, we'd have to back out the successful operation, since I might  
not know that PUT will fail without actually trying it first.

   Next up, 14.25 (If-Modified-Since) implies in the first paragraph  
that it applies to all methods, but then only proceeds to describe  
what to do with a GET, and even then, a GET with no Range header.  If  
I get an IMS for a PUT, is that a valid request?  How about a DAV  
COPY?  Presumably in that case would apply, if valid, to the source  
resource, not the destination.

     -wsv

Re: Some RFC 2616 questions

[Joe Orton <jo...@redhat.com>]

On Thu, Aug 18, 2005 at 03:56:48PM -0700, Wilfredo Sánchez Vega wrote:
>   The spec for If-{None-}Match and If-{Un}Modified-Since is driving  
> me batty.
> 
>   The biggest item has to do with having to know the response code  
> for the request without processing the request.  Specifically, 14.24  
> (If-Match) and the others have a requirement like:
> 
>         If the request would, without the If-Match header field,  
> result in
>         anything other than a 2xx status, then the If-Match header  
> MUST be
>         ignored.

I could make a wild guess that this is an attempt to specify some 
evaluation precedence to the header; so e.g. if you know you have to 
issue a 400 because the request is otherwise syntactically invalid, then 
you must ignore the if-match.  Likewise for a 401.  But it doesn't seem 
to make much sense as a MUST requirement, agreed.

>   Next up, 14.25 (If-Modified-Since) implies in the first paragraph  
> that it applies to all methods, but then only proceeds to describe  
> what to do with a GET, and even then, a GET with no Range header.  If  
> I get an IMS for a PUT, is that a valid request?  How about a DAV  
> COPY?  Presumably in that case would apply, if valid, to the source  
> resource, not the destination.

Yes, it should be valid for all methods certainly - it just applies to 
the resource identified by the request-uri, regardless of method; so 
that is the source for a COPY and MOVE, indeed.  (iirc the I-M-S/I-U-S 
headers do work properly with mod_dav, but not the if-match ones)

joe