- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Tue, 18 Mar 2008 20:06:49 +0100
- To: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
- Cc: Mark Nottingham <mnot@mnot.net>, Lisa Dusseault <lisa@osafoundation.org>, Werner Baumann <werner.baumann@onlinehome.de>, ietf-http-wg@w3.org
On Tue, 2008-03-18 at 12:22 +0100, Robert Siemer wrote: > Apaches weak etags would provoke that, which for me makes no sense. - > The server obviously does not care if some client stays with old and > possibly completely "wrong" data. This is what we have now and we could > judge: > > a) that's fine, the server sends weak etags whenever it likes In the Apache case I say it's fine. The weal ETag returned by Apache is built from a number of sources in fact making it a quite strong etag. The only reason why it's weak is because it is possible there is a local process outside of Apache which modifies the file in such manner that stat() of the file would not notice any difference (no change in size, modification time or inode number). The likelyhood that you actaully see two semantically significant objects with the same weak ETag from Apache is very low in nearly all applications, even if you have a lot of sub-second updates of the object. And if that becomes a problem for you then a small change in your server-side application to write to new files and rename instead of overwriting parts of existing files would make the server behave well. > I personally don't like careless server behaviour like a); a > document that changes "so often" is in my view probably out of date. > Servers should not generate an ETag in this situation if they have no > better means. That weak ETag is a lot stronger conditional than Last-Modified on such objects. Last-Modified would not notice nearly any of the sub-second updates, while the weak ETag used by Apache detects almost all except for a very specific case. Worth noting in this discussion is that Apache has a similar cornercase where it's strong ETags malfunctions, and thats if you run a backend application which modifies parts of files without touching the last modification date. Thats somewhat less likely than an application rewriting parts of a file multiple time in a sub-second but both is quite unlikely in nearly all real life uses. The only problem I have with how Apache uses weak etags is that it can not match then in a subsequent If-None-Match, not even within the same second. But that's a minor implementation detail and not a protocol violation (only sub-optimal behavior). Regards Henrik
Received on Tuesday, 18 March 2008 19:08:47 UTC