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

This is all fine but I think I am still far behind you. You keep pointing
out it is impossible to implement but I'm actually  interested in who might
not need it? How can I make my question any more clear that I am not asking
about if current servers implement it or not? I'm just trying to figure out
the practicalities of number of types of application in each camp.


On 11/27/05 7:59 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 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 Monday, 28 November 2005 01:58:41 UTC