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