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
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:
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
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.
Again: do you have any evidence of *shipping* clients making that
Best regards, Julian
Ietf mailing list