You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@apache.org> on 2003/01/30 07:18:21 UTC

Re: cvs commit: httpd-2.0/modules/dav/main util.c

>   Allow mod_dav to do weak entity comparison function rather than a 
> strong
>   entity comparison function.  (i.e. it will optionally strip the W/ 
> prefix.)

That doesn't really follow the spirit of etag validation in HTTP.
In theory, the client is not allowed to use weak etags for anything
other than cache consistency checks, so this won't help any client
that is actually HTTP-compliant.  It would be better to send a strong
entity tag in the first place.

....Roy


Re: cvs commit: httpd-2.0/modules/dav/main util.c

Posted by Justin Erenkrantz <je...@apache.org>.
--On Wednesday, January 29, 2003 10:18 PM -0800 "Roy T. Fielding" 
<fi...@apache.org> wrote:

>>   Allow mod_dav to do weak entity comparison function rather than
>>   a  strong
>>   entity comparison function.  (i.e. it will optionally strip the
>>   W/  prefix.)
>
> That doesn't really follow the spirit of etag validation in HTTP.
> In theory, the client is not allowed to use weak etags for anything
> other than cache consistency checks, so this won't help any client
> that is actually HTTP-compliant.  It would be better to send a
> strong entity tag in the first place.

Julian Reschke from the IETF WebDAV WG filed a PR saying that we were 
in violation of the RFC because mod_dav didn't allow weak entity 
tags.  This is part of the 'Summary of If header eval tests' thread 
on the w3c-dist-auth mailing list.

The problem has to do when a weak entity tag is generated on a file 
that has just changed (therefore, MUST be weak).  When a request 
tries to use that weak entity tag on a If: in a subsequent request 
(after the etag is now strong), mod_dav would reject it because it 
was weak.

Julian said that was incorrect behavior.  I'm not currently in a 
position to disagree.  Feel free to disagree with him.  I have to 
admit that this area is *very* unclear in the RFCs.  I tend to say 
that we should be forgiving in this case (liberal in what you accept, 
blah, blah).  But, I have no problem backing it out if the protocol 
gurus say so.  =)  -- justin