Re: Etag-on-write, draft -04

   Well, two things.

   One, the client doesn't really know that the weak ETag is going to  
become a strong ETag later, unless it makes assumptions about Apache's  
behavior.

   Two, I don't think you can assume that "X" and W/"X" are at all  
related to each other.  In Apache's case, there is no such guarantee,  
because the same weak ETag may be issues to different versions of the  
document (if it is edited more than once in the same 1-second window),  
the data you got with an ETag of W/"X" may be completely different  
than the data that later exists with an ETag of "X", or even the same  
W/"X" you got.

   Apache's behavior works more-or-less for caching proxies, but it's  
not really great for authoring clients.  The weak->strong promotion  
itself isn't broken per se, but the same data having a changed ETag is  
a bit of a bother.  That different data exist with the same (weak,  
brief) ETag seems like a violation.

	-wsv


On Nov 29, 2006, at 6:35 PM, Henrik Nordstrom wrote:

> ons 2006-11-29 klockan 16:25 -0800 skrev Wilfredo Sánchez Vega:
>
>>>   ETag behavior on WebDAV FS is already broken in the most common
>>> case, by the way.  I frequently have a document open on a DAV
>>> volume, and a second after I save it, my editor thinks the document
>>> changed (because Apache changed the ETag that it never should have
>>> sent on PUT in the first place).  Thus, the most common case (Apache
>>> server) is already broken today, partly for reasons (the weak-
>>>> strong change) that are not addressed in this draft at all, because
>>> they are unrelated, and arguably an Apache implementation problem.
>
> Can you please elaborate on what the actual problem with the Apache
> approach is? To me it smells like this is actually a slightly dumb
> client not understanding ETag semantics, and nothing wrong at the
> server.
>
> I haven't looked in detail at what Apache does, but I assume the  
> ETag as
> such is still the same, just that it's now a strong ETag. If so then
> what's the problem? It's still the same ETag indicating that the  
> content
> has not changed in semantics, but octet equality is not guaranteed
> (well, it pobably is in the Apache case, but can not be counted in by
> specs). The temporary weak ETag in this context has the potential of
> being a much stronger validator than Last-Modified ever can be.
>
> The only thing I see troublesome with this approach is the silly fact
> that the use of the weak etag is not allowed as If-Match condition on
> subsequent PUT when saving the next change to the same document. This
> forces the client to first do a HEAD to get the strong ETag, make it's
> own compare to ensure the content is still semantically equivalent and
> then PUT using the strong ETag.. or alternatively ignore this silly
> restriction and use the weak ETag in PUT If-Match assuming the server
> will swallow it even if tecnically not allowed..
>
> Regards
> Henrik