W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Jun 2006 02:14:31 +0200
Message-ID: <44988F67.9050803@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Wilfredo Sánchez Vega <wsanchez@apple.com>, ietf@ietf.org, Ted Hardie <hardie@qualcomm.com>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>

Lisa Dusseault schrieb:
> My assertion was that if a strong ETag is returned, Xythos WFC assumes 
> that what it PUT was what the server stored, and it seems you agree.  
> You found that if a Last-Modified is returned instead, WFC makes the 
> same assumption -- naturally, they're very similar.

It seems that the client always assumes that the server does no 
content-rewriting, no matter what it returns. So it's incorrect to 
assume it makes specific assumptions about ETags on PUTs. It doesn't.

> You're probably quite right about the general case, that existing WebDAV 
> clients don't handle content-rewriting servers at all.  What's the best

Several clients handle it well, because they don't have a local content 
cache. Examples are Microsoft Office, Microsoft Webfolder, and the SAP 
Netweaver KM.

> thing a content-rewriting server can do in this situation?  I would hope 
> that if a client receives neither an ETag nor a Last-Modified in a PUT 
> response, then the next time it synchronizes and sees an ETag that it's 
> never seen before, the client downloads the resource.  This allows the 
> content to eventually get synchronized although perhaps not as fast as 
> would be ideal.

As there's no guarantee in HTTP about content rewriting not occurring, 
clients should always re-sync (at some point of time). An optimization 
(which happens to be the one I've been proposing several times now) 
would be a way for the server to indicate that content was *not* 
rewritten, avoiding the additional retrieval.

> But CalDAV clients will have to handle content-rewriting servers at 
> least handling events (calendar component resources), because during 
> protocol development we heard from a couple server developers that 
> they'd need to add custom iCalendar properties to an event as soon as it 
> was stored, thus rewriting the content.

Yes. I'm not sure how this is different from the generic case, though.

Best regards, Julian
Received on Wednesday, 21 June 2006 00:14:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:19 UTC