Re: PROPOSAL: Weak Validator definition [i101]

On Mar 17, 2008, at 2:57 PM, Lisa Dusseault wrote:
> Strawman proposal "Document Apache": Weak ETags could be documented  
> the way they are used today in Apache.  I believe this effectively  
> delays a second PUT until a second has passed since the PUT that  
> cause the weak ETag to be created; then the weak ETag is converted  
> to a strong one that the client can consider as equivalent.  Be  
> more clear about how "W/[tag]" ~= "[tag]" for any value of [tag]  
> (that doesn't begin with W/).   The value of weak ETag therefore  
> becomes one of conserving the server's resources by using a cheap  
> way to calculate ETags, that happens to also push clients to delay  
> changes that contain If-Match conditionals.

Just to be clear, this is only true for Apache when the core file
handler is being used to process responses and the default ETag
generation is configured to use second-resolution last-modified
dates.  For example, Apache with Subversion on the back-end has
very different ETags.  The reason for making the second-resolution
entity-tag weak in this case is the possibility that two updates
made within the same second have the potential to confuse a later
Range request based on the first update.

Apache is supposed to be able to return 304 to a GET based on
weak comparison of entity-tags.  There is a bug report that says
we don't do that at the moment, but I haven't had time to figure
out if (or why) that is the case.

> Strawman proposal "Read-Only": Let the server decide when to use  
> weak ETags, but only on read-only resources (writable resources  
> must offer strong ETags or none.)  Document the server's goal here  
> is to allow caches to serve old resources if they are similar  
> enough to the most-recent version.  Thus, the server's test here is  
> not "Are the versions semantically equivalent", but "Should caches  
> refetch."

I don't believe that the server is capable of knowing such a thing.
The vast majority of resources that are "read-only" are, in fact,
writable behind the interface, and it is primarily those writes
that are at risk of the twice-in-one-second updates.  In any case,
it is an implementation detail -- HTTP has no business limiting the
implementation behind the interface.

> Strawman proposal "Die die die": get rid of weak Etags.  Do this by  
> making the W/ prefix simply part of the ETag.  Alternatively, do  
> this deprecating: recommend clients to ask again or not use etags  
> that begin with W/.

Old servers will exist for a long time.

> In any case, I find that the paragraph on modification time is  
> inconsistent with any language about semantic equivalence; there's  
> no relationship between whether a resource was modified in the last  
> second and whether it's semantically equivalent.

Agreed, I see no reason to say anything about semantics here.
It should just be defined in terms of what the server is saying
and let the client adjust its behavior as it deems appropriate.

....Roy

Received on Tuesday, 18 March 2008 00:51:06 UTC