httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38034] - PUT If-None-Match: "*" failures
Date Thu, 26 Jul 2007 21:05:56 GMT
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 werner.baumann@onlinehome.de  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message