Re: PROPOSAL: Weak Validator definition [i101]

Mark said he'd only seen one proposal on this issue.  There are so  
many ways this could be resolved, I'm following the advice of my  
Systems Design professor who said "You have no idea if you have a  
good solution, if you have only thought of one solution."  How about  
these:

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.

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

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

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.

Lisa


On Mar 16, 2008, at 11:37 PM, Mark Nottingham wrote:

>
> Hmm. Doesn't resolving it on the side of keeping semantic  
> equivalence beg the question of what semantic equivalence is -- and  
> is there any way to define it except in a server-specific fashion?
>
>
> On 17/03/2008, at 1:44 PM, Robert Siemer wrote:
>
>>
>> On Sun, Mar 16, 2008 at 10:35:33PM +0100, Werner Baumann wrote:
>>> Robert Siemer wrote:
>>
>>>> There are. At least some of my CGI scripts use them. - I would not
>>>> discard that many other CGIs do the same.
>>>>
>>>> To see no useful weak etag implementations within the static file
>>>> serving code among common servers does not surprise me at all. -  
>>>> How
>>>> should they know about semantic equivalence?
>>>>
>>>> I still don't know why this mecanism has to be an illusion.
>>>>
>>> I don't say, it *has to be* an illusion. I say it *is* an  
>>> illusion, when
>>> confronted with current practice. And the spec is self- 
>>> contradictory,
>>> because it contains two mutual exclusive definitions of weak etags.
>>>
>>> You can resolve this to either side. But the only realistic way  
>>> seems to
>>> be to adapt the spec to current practice.
>>
>> Current practice is to deliver weak etags that never match later on.
>> These are based on "weak last-modified" dates. I hope that this
>> useless practice ("we always generate ETags") never makes it into the
>> spec!
>>
>> As clients will do the same independent on which side we pull, I  
>> don't
>> see "semantic equivalence" already lost.
>>
>>
>> Robert
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

Received on Monday, 17 March 2008 21:57:51 UTC