RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, February 26, 2003 11:10 PM
> To: 'Jason Crawford'; 'Julian Reschke'
> Cc: 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)
>
>
>
> > Let's use the SHOULD and let implementers understand why they SHOULD
> > implement strong Etags.  Let the implementers weigh the  "difficulty"
case
> > against the benefit case themselves.   And let's let the  implementors
that
> > don't follow through on the SHOULD know if they are impacting  us as
users
> > and if we're tempted to use a different product.  I know that  user
feedback
> > is a strong motivator for most software developers.
>
> OK, this is actually very related to an argument in favour of "MUST
> support strong ETags".  Unless it is a requirement of servers, clients
> simply won't implement it. And if clients (and client libraries) don't
> implement it, users and even many developers don't have the choice.

I really really have little sympathy for this statement. Clients can *right
now* detect whether the remote server has strong etags. Some servers do not
have them, some offer them after a delay after PUT (IIS, Apache), others
support them always for specific backends (let's assume this applies to
Slide/Tamino, SAP and Xythos).

If a client decides *not* to take advantage of the strong etag just because
it will have to take into account the case that the strong etag  *isn't*
available, then it's really not the spec's or the server implementor's
fault. Handling a GET/modify/PUT sequence well in both cases really isn't
rocket science:

1) LOCK the resource.
2) GET the resource. If it comes with a strong etag, remember it.
3) Let the user modify the resource.
4) Do a PUT with If header, supplying lock token and optionally the etag
when it was present in step 1.
5) UNLOCK.

If this really is too complicated, I don't see how we can help the client
programmer. Note that the only conditional code appears in step 4 and may be
a single line statement such as:

if (etag != null)  addEntityTagCondition(ifheader, uri, etag);

> It's a chicken/egg problem, too.  Server implementors won't take the
> pains to implement ETags because they know most existing clients ignore
> ETags.  How do we exit from this vicious circle?

That's really an interesting claim. Can you prove it?

As far as I can tell, servers really do their best to come up with strong
etags, but if they can't do it reliably, they don't (which clearly is better
than claiming strong etag support when it doesn't work). I suggest you get
the source code for moddav and try to appreciate how much effort was put
into creating strong etags when feasible, and to fallback to weak ones when
it isn't.

Speaking of clients: does the Xythos WebDAV client take advantage of entitiy
tags?

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 26 February 2003 17:29:05 UTC