W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: PROPOSAL: Weak Validator definition [i101]

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
Message-Id: <1205867209.18425.138.camel@HenrikLaptop>

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).

Received on Tuesday, 18 March 2008 19:08:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC