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 Fri, 27 Jul 2007 08:09:19 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 julian.reschke@gmx.de  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message