Lisa Dusseault schrieb:
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?
Chandler is not released and obviously operating based on what the
CalDAV spec currently says.
Regarding the Xythos client: I just did some tests, and as far as I can
tell the behavior is the same independantly of whether the server
returns an ETag in PUT: the client always assumes that content was not
rewritten, and in the absence of an ETag uses the Last-Modified date to
check. So it seems that it doesn't handle content-rewriting servers at
all, right? (one needs to manually purge the cache to get the actual
content).
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?
No. And I don't think it necessarily needs to, unless it assumes that it
can use the ETag in subsequent GET/Byte-Range operations.
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.
Well, it's a broken choice. There are servers that rewrite content and
still return ETags upon PUT, and HTTP allows them do that.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf