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=42987>. 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=42987 ------- Additional Comments From [EMAIL PROTECTED] 2007-12-27 12:51 ------- I am referring to http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/[EMAIL PROTECTED] and would like to propose this solution. Precondition: Getting a strong Etag immediately (withing 1 second) after changing a resource is not important for many applications of HTTP, but is very important for WebDAV. For this reason the bug must be fixed differently in ap_make_etag() and in mod_dav/mod_dav_fs. Apache core, ap_make_etag() --------------------------- If the file mtime is within the same second as the request time: - do not create and not send an etag - send header Cache-Control: no-cache (to prevent a fallback to using Last-Modified for cache validation) Note: There are no backward compatibility issues with dropping the weak etag. The meaning of Apache-style weak etags is "never-matching-etag". It's single effect is, that a cache might store the entity, only to drop it on the next request. But this misuse of weak etags has the effect to encourage/force clients to implement handling of weak etags in a way that violates the RFC and might cause problems whenever someone uses weak etags in an RFC-compliant way. WebDAV (mod_dav_fs) ------------------- WebDAV-clients need a strong etag immediately after a PUT to avoid a lot of traffic. To avoid race conditions, this strong etag must be returned in the response to the PUT-request. Because of the limited time resolution of many file systems this can not be created with information from the stored file alone. Using some kind of hash function would consume to much CPU-power and does not guarantee really strong etags. So I vote for storing the strong etag as a WebDAV-property. This solution imposes a restriction on the administrator of the server: - resources must only be changed via WebDAV (to not bypass the etag maintainance of mod_dav_fs) - if the administrator feels the need to change the repository via the local file system, serving PUT-requests must be stopped one second before, and only be restarted one second after the changes are made. This restrictions may not be acceptable in some cases, so a configuration option is needed, to turn this off and fall back to ap_make_etag(). To be reliable and to catch most of the errors of lazy administrators, I propose this logic: 1. The etag is stored as a WebDAV-property. It consists of two parts. Part 1 is the same as created by ap_make_etag(). Part 2 is a simple counter. It is set to 0, when the mtime changes. If the file is changed without change in mtime, it is incremented. 2. on PUT-requests (and other requests that change the file) - get the old etag property - change the file - create Part 1 of the new etag - compare the new and the old Part 1: if they are equal: increment Part 2 otherwise take the new Part1 and append Part 2 with value 0 3. on GET, HEAD, PROPFIND and other requests that don't change the file (this also applies when checking If-Match and If-None_match headers) - get the stored etag property - create Part 1 from the file - compare Parts 1; if they are different replace the etag property by the new Part 1 with Part 2 = 0 This will catch most of the cases, where resources have been changed via the local file system. There is a small chance to get a wrong etag, if - a file has been changed via WebDAV - after this, but within the same second, the file is changed via the local file system (neglecting the good advise given in that fine manual) Additionally: When strong etags are enabled this way for mod_dav_fs, responses to PUT requests should always include Etag and Last_modified headers. To make clear, why this is important for WebDAV: At the moment, a WebDAV-Client, that wants to save a file and have the file available after that, has to - send a LOCK-request - do a HEAD-request to check for changes or existence - send the file via PUT - retrieve the file via GET (unconditional) - UNLOCK That's five requests, and there is still a potential danger, as locks are not guaranteed to work; so the file might be changed between HEAD and PUT. Having proper etags and working If-Match and If-None-Match, this transaction would be atomic: just one PUT with If-Match or If-None-Match header, and the client would have a valid strong etag for use in the next request. I am not able, to prepare a patch. It would take me at least 3 month to learn enough about apche and another three month to understand and change mod_dav_fs. Werner -- 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]
