DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38034>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38034 ------- Additional Comments From [EMAIL PROTECTED] 2007-07-26 14:05 ------- > Why would a client remove the weakness indicator? Because the weakness indicator sent by Apache is nonsense. When I send a PUT request and immediately thereafter send a HEAD request, I always get a weak Etag from Apache, say W/"19e60b-20-279033c0". If I do the HEAD request some seconds later, I get the strong Etag "19e60b-20-279033c0". Neither Apache nor somebody else changed the content, it is just what I sent in the PUT request. And this makes no sense to the client. The reason is in modules/http/http_etag.c, ap_make_etag(): * If the request was made within a second of the last-modified date, * we send a weak tag instead of a strong one, since it could * be modified again later in the second, and the validation * would be incorrect. What should be the sense of this (would be nice if you could explain it to me)? - changes may happen at any time. Why are young files bad and old ones good? - are there race conditions within in Apache, so the Etag will not match the body of the response (mtime and etag are evaluated at one time, the response-body some time later)? In this case a weak Etag is just as wrong as strong one. Why should this race condition occur only within 1 second after the file has been modified? If this realy is the case, it needs debugging. - when the Etag matches the body of the response, it is completely ok to change the content on the server 0.1 microsecond later (because this will change Etag). As long as Apache (or some module) does not distinguish between "semantically significant changes" and changing some byte, there is no reason for weak Etags (see RFC 2616, 13.3.3 Weak and Strong Validators). For any caching WebDAV-client, it is essential to get the Etag of files uploaded to the server. If this is impossible, the client has to throw away the local copy and download it from the server again -- but only after waiting at least one second. Real world: As long as one uses only standard WebDAV (RFC 4918) with Apache mod_dav (I don't know about extension like versioning), or any other WebDAV-server, removing the weakness indicator is no problem at all. davfs2 does it, and I never heard of any problem that might be related to this. P.S.: Servers, that don't edit the body of a PUT, should send a strong Etag and Last-Modiefied in the PUT-response, allthough the WebDAV Working Group was not able to address this problem. It would avoid race conditions. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
