W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: ETags, next call, was: Notes on call from today ...

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 27 Nov 2005 16:59:54 +0100
Message-ID: <4389D7FA.5070506@gmx.de>
To: Cullen Jennings <fluffy@cisco.com>
CC: WebDav <w3c-dist-auth@w3.org>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

Cullen Jennings wrote:
> Some people have been advocating a profile approach. I am simply trying to
> figure out if there are a large contingent of applications for both
> profiles. I have heard many applications (much more than just file system)
> that would not be impacted by no strong ETags so I am convinced that group
> is large, what I am looking for is what are the applications in the other
> group that don't care if they get back a weak or strong ETag?

First of all, I'm not aware of any widely deployed WebDAV clients that 
currently *require* strong ETags, because they wouldn't work with many 
servers. If somebody disagrees here, please provide details.

Furthermore, it seems to me that many still underestimate what requiring 
strong ETags means. Let's see what RFC2616 says...:

'A "strong entity tag" MAY be shared by two entities of a resource only 
if they are equivalent by octet equality.'


That means that requiring strong ETags rules out *any* kind of server 
that actually doesn't store content binary. Some examples are:

- XML based databases with WebDAV interfaces (Tamino, Oracle?)

- Severs specializing in / optimizing for specific content types (Atom, ICS)

In particular I'm surprised to hear that implementors of CalDAV clients 
expect the servers to provide strong ETags for calendar entries. A 
calendar server that has a ICS store has basically the following options:

- store the binary representation sent with PUT for every entry 
(expensive), or

- do not return an ETag at all after PUT, because the ETag returnen upon 
GET will depend on what the server's default binary representation of 
the calendar object will be (and that's unlikely the same as sent by 
arbitrary clients)

On the other hand, a server that implements RFC2616/RFC2518 would just 
use weak ETags, allowing to reformat the content as long the semantics 
stay the same.

> Let me a related questions to client implementers? On the phone call the
> other day, knowledgeable server implementers seemed to imply that the right
> solution for clients that got bag a weak ETag but needed a strong one was to
> poll the server until they got back a strong one. Does any client do that?

I would be surprised, because there's no guarantee that this will 
actually work (a server may decide to use weak ETags all the time).

Best regards, Julian
Received on Sunday, 27 November 2005 16:01:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC