You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/01/29 06:05:11 UTC

DO NOT REPLY [Bug 16451] - If header check fails when etag test present

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16451

If header check fails when etag test present

jerenkrantz@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jerenkrantz@apache.org
             Status|NEW                         |ASSIGNED



------- Additional Comments From jerenkrantz@apache.org  2003-01-29 05:05 -------
What is the ETag header for this resource?  If you do a HEAD, are you getting the W/ prefixed?  If the ETag *is* identical, it works for me.  I tried with mod_dav_fs and mod_dav_svn which don't seem to use weak entity tags.  (Note that both of them implement the getetag hook.  A provider that doesn't implement it would fail here.)If you can provide a reproduction case that produces a weak entity tag, we can look at it further.  The question remains that if something is producing a weak entity tag, should it compare with the W/ prefix or strip it first?  I think in order to be true to the RFC, we should test the entire ETag with the W/ prefix (if passed).  It is truly an opaque token.Comments welcome.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org