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

[Julian Reschke]

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