Re: ETags and concurrency control

Yes. I tend to think that weakness doesn't help here; there's no  
guarantee about the nature of the change, and if the server is that  
unsure about the actual content, it shouldn't be sending an ETag at  
all (or, more likely, allow administrators to configure whether or not  
ETags are sent, with a sensible default, depending on how they use the  
FS).

Adding weakness to the mix doesn't provide any benefit (as many have  
pointed out), and just muddies the concept.


On 03/05/2008, at 5:31 AM, Werner Baumann wrote:
>
> Julian Reschke wrote:
>> I'd say that it's the server's choice to generate these kinds of  
>> ETags. Nut if it does, and they aren't reliable enough for a write  
>> operation, it could still reject the request... My understanding  
>> was that we want *allow* servers to support weak etags on write  
>> operations, not require.
> Take the case of Apache-style weak etags (based on insufficient time  
> resolution).
> If the server cannot know whether the the entity changed since the  
> etag was generated, it will always have to reject the request.  
> Allowing weak etags in these requests will only result in an  
> additional round trip.
> If the server can know whether the entity changed since the etag was  
> generated, there is no need for the etag to be weak, it *is* strong.
>
> Things are quite different, when you think of weak etags meaning not  
> byte-by-byte, but semantically equal. But there is the whole mess.  
> These are two completely different and unrelated concepts.
> - insecure (or unreliable): there is a small chance, that the entity  
> changed without changing the etag, and the change may be completely  
> arbitrary.
> - semantically equivalent, though not byte-by-byte equal.
>
> As long as you try to get this two concepts into one definition of  
> weak etag, it will stay a confusing mess.
>
> Werner
>


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 8 May 2008 07:10:18 UTC