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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] Status|NEW |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
