Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Julian Reschke wrote:
> >* Erroneous only if the server is allowed to modify the entity it
> >receives in PUT _and_ respond with an Etag which matches that modified
> >entity.
> 
> That wouldn't always be a problem. There are lot's of scenarios where it 
> would be ok to do that, as outlined in 
> <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.A.1>.

The usage in that article should use a weak Etag, not a strong one.
>From the article:

    Note that the only problem here is that the client doesn't have an
    exact copy of the entity it's editing. However, from the server's
    point of view this is entirely irrelevant, because the "Revision"
    keyword will be automatically updated upon every write anyway.

Think about what happens if the client were to do a byte-range GET to
get part of the entity at this point (e.g. because it's editing a
large entity, and decides to discard _part_ of it from its cache).
Because of the substitution at the server, the byte ranges won't match
and the file being edited will get really messed up.

Also, think about what happens if the user _wants_ to view the actual
content at the server including substitutions made by the sever.
Either they won't be able to, as intermediate proxy caches will
continue serving the entity sent by PUT, no matter what client they're
using (or even multiple clients).  Or they can use a client which
disables proxy caching entirely even when that is unnecessary.

This is why the usage in
    <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.A.1>
should use a weak Etag.

> >To avoid such errors _in new deployments_ which are intended to
> >interoperate with existing ones, one (or both) of the following are
> >suitable:
> >
> >   1. If a server sends a strong Etag in a PUT response, future
> >      conditional requests using that Etag will only match if the
> >      entity has not changed at all.  (If a server sends a weak Etag
> >      in a PUT response, future conditional requests using that Etag
> >      will only match if the entity has not changed according to the
> >      meaning of "weak".)
> 
> That would defeat some uses cases which (IMHO) are legal as per RFC2616 
> (where octet-by-octet identity isn't required).

Where octet-by-octet identity isn't required, that's what _weak_ Etags
(beginning with "W/") are for.  It's ok to send those in a PUT
response without confusing clients.  Or at least, any clients which
treat weak Etags as though they were strong deserve to be confused, as
it's been in the spec forever.

> >   2. If a client receives a strong Etag in a PUT response, it should
> >      ignore it.
> >
> >If there are already deployed clients which don't satisfy requirement
> >2, then it would be appropriate to insist on requirement 1 in future
> >specifications, so that future deployments interoperate with existing
> >ones.
> 
> >If there are already deployed servers which don't satisfy requirement
> >1, then it would be appropriate to insist on requirement 2 in future
> >specifications, so that future deployments interoperate with existing
> >ones.
> 
> I know these servers exists and are deployed, because I wrote one of 
> them :-)

Tsk! :)

> >But if there are _both_ deployed clients and servers which don't
> >satisfy those requirements out there, those will already fail to
> >interoperate with each other.  There is no specification which can fix
> >this.  However, the choice of 1, 2 or both will affect
> >interoperability of future deployments with the existing onesa.
> 
> As far as I can tell, the interop problem already is there (that's why I 
> wrote the draft suggesting an approach that I *think* is faithful to 
> RFC2616 and resolves the problem for new clients and servers, as 
> discussed in XCAP and CalDAV).

-- Jamie

Received on Thursday, 14 September 2006 10:13:42 UTC