- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 27 Nov 2005 16:59:54 +0100
- 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.' (<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.11>) 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