Re: Etag-on-write, draft -04

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