- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 26 Feb 2003 23:28:30 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Jason Crawford'" <nn683849@smallcue.com>, "'Julian Reschke'" <julian.reschke@gmx.de>
- Cc: "'Clemm, Geoff'" <gclemm@Rational.Com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> 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