- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 14 Sep 2006 13:31:27 +0200
- To: Jamie Lokier <jamie@shareable.org>
- CC: Lisa Dusseault <lisa@osafoundation.org>, Helge Hess <helge.hess@opengroupware.org>, HTTP Working Group <ietf-http-wg@w3.org>, Jonathan Rosenberg <jdrosen@cisco.com>
Jamie Lokier schrieb: > Julian Reschke wrote: >> Lisa Dusseault schrieb: >>>> That's incorrect, at least as the Xythos client is concerned (see >>>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0090.html>). >>>> >>> I can't really see how we disagree here. If the server returns a strong >>> ETag, the Xythos client assumes that the content was written as sent. >>> Later, when the client attempts to refresh its cache, if the ETag is >>> still the same, the client happily continues using the entity that it >>> PUT. Thus, a user can refresh and refresh and refresh, and still not >>> see quite what the server has stored and other clients/users see. >> Yes, but if the server *doesn't* return an ETag (as mandated by CalDAV), >> it simply uses the Last-Modified time stamp again. That is, it doesn't >> work at all with servers rewriting the content upon PUT, no matter >> whether they return an ETag or not. > > But why not a weak Etag, along with "Cache-Control: > max-age=0,must-revalidate"? (Or "proxy-revalidate" if you don't mind > _that particular_ client reusing the sent entity). RFC2616 says that weak etags can't be used with PUT/If-Match. So of what use would that be? Best regards, Julian
Received on Thursday, 14 September 2006 11:31:34 UTC