Re: PROPOSAL: Weak Validator definition [i101]

On Tue, 2008-03-18 at 22:39 +0100, Robert Siemer wrote:
> Nothing comes to a "grinding halt" if we don't cache these responses. 

I didn't say that. I said that the wold will come to a grinding halt if
everything taking place needs to be 100% guaranteed. For most things
it's good enough if it's within reasonable doubt.

> You say the likeliness is high that a same second change is small, I say 
> the likeliness is high that the change is significant.

I say that the assumption that it's very unlikely that there is a
significant in-place edit (overwrite, not replace) change within the
same second and which do not change the filesize is for most use cases a
perfectly valid assumtion.

I do not say that this is true in every possible imagineable situation,
but there is a lot of things that is not true in every situation. And
for that reason there is knobs to tune these details in the web server.

> If weak etags mean "it was the only feasible way to generate one" then I 
> would advocate to stop using them client side. They just degrade cache 
> transparency with no real benefit.

I don't agree at all with this.

> If I hit five times the "reload" button of my browser, what should 
> happen? Should there be space for the possibility to see the wrong page 
> because the browser used a weak etag in a conditional request?

Sure, just as will happen if just Last-Modified was sent. But with the
weak etag this corner case is a lot smaller. See below.

In this specific case the weak etag do improve things a lot compared to
just Last-Modified as the weak etag is built from more sources than just
last modification time. Based on the Apache algorithm (and assuming
Apache gets fixed to process the conditional with a positive outcome)
the weak etag in If-None-Match detects changes in the following
conditions where If-Modified-Since does not:

- Some text was added or removed in the same second. (different file
size)

- File was completely replaced by a different file (different inode from
write -> rename).

- An older backup of the file was restored, including the older
modification time (different modification time in the past).

And in addition to this the weak etags is very useful in cases where the
server actually knows the semantics.

Regards
Henrik

Received on Tuesday, 18 March 2008 22:02:16 UTC