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

From: Jason Crawford <[email-masked]>
Date: Wed, 26 Feb 2003 15:34:29 -0500

I again tend to agree with Julian.

What Lisa has said seems true, but it's not compelling as much as it simply
weakens Julian's position.

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.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 26 Feb 2003 14:09:45 -0800

> 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. 

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?

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 26 Feb 2003 23:28:30 +0100

> From: [email-masked]
> [mailto:[email-masked]]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)
>
>
>

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);

> 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

---

From: John DeSoi <[email-masked]>
Date: Thu, 27 Feb 2003 08:26:09 -0500

>is a strong motivator for most software developers.

Further: There is more than one way to implement locking. My server 
already had a locking mechanism, so I had no desire to implement 
WebDAV locking at all. I just wanted a few features to make it easier 
for users to upload files. But then I got sucked into it because OS X 
refused to allow writes without locking. I found the locking part of 
WebDAV to be the most complex and problematic part to implement. At 
times it made me wish I had taken another approach.

Best,

John DeSoi, Ph.D.