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, JulianReceived on Tuesday, 20 June 2006 16:56:50 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:22:14 GMT