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-27 01:09 ------- (In reply to comment #7) > > Why would a client remove the weakness indicator? > Because the weakness indicator sent by Apache is nonsense. But that doesn't mean that people should apply hacks to their clients. > 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. It makes perfect sense for clients that just need a weak etag, such as for making GET in the browser conditional. > 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? As long as the timestamp of the file equals the system time, it can't be used to compute a strong etag (because the file can change again in the same interval). Once it's not the same anymore, it can be used to compute a strong etag. > - 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). That depends on the resolution of the system clock. > 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. Yes, that's a problem. But putting hacks into the clients (removing the weakness indicator) is the wrong way to handle this. > 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. That's because nobody has tested with other WebDAV servers that may assign weak etags for other reasons than the one you see in Apache/moddav. > 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. Actually, servers should send the ETag always, no matter whether the body was changed (IMHO). See proposal in http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-latest.html (follow ups with respect to this on the http-wg mailing list, please). -- 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]
