ietf
[Top] [All Lists]

Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

2006-06-20 08:12:12
Xythos WFC and Chandler (the Zanshin library that does WebDAV in python) behave this way and make the assumption I describe. How else would you expect a caching or synching client to behave after doing a PUT, when the implementors of those clients were pretty sure that WebDAV servers stored the content without mucking with it?

Your turn now: do you have an example of a general-purpose (e.g. file sharing, site synch) shipping client that handles ETags and caches or synchronizes content, which does a full GET of the content immediately after PUT even if it receives a strong ETag?

Even if there are such clients, the behavior we describe avoids nasty errors on both such clients and clients like WFC. It's the conservative choice.

Lisa

On Jun 19, 2006, at 12:41 PM, Julian Reschke wrote:

Lisa Dusseault schrieb:
On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote:
  I agree with Julian.

As we've mentioned before, Apache returns a weak ETag on PUT, which turns into a strong ETag sometime later. If clients rely on being able to use that ETag on a GET later, they won't work with Apache, and IIRC, Apache is pretty popular.

The ETag requirements in the draft are what many clients authors might *like* to be the common case, but it is most certainly not so today.
It's worse than that; many client authors *assumed* that to be the case, and implemented and deployed their clients assuming that if the client receives a strong ETag in response to a PUT, it has no further work to do to synchronize that resource. So the deployed base says that *is* the case today. I don't feel our document makes this situation any worse than the deployed base of clients already does.
Lisa

Again: do you have any evidence of *shipping* clients making that assumption?

Best regards, Julian




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>