- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 14 Sep 2006 15:29:52 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- 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>
Julian Reschke wrote: > >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? Point, I hadn't noticed. If any part of the spec would be changed, I'd suggest that :) Plus allowing PUT entities to be cached by proxies, iff the PUT response has an Etag. And I concede all your points about the meaning of the existing spec., and see that all clients and servers which exactly implement the existing spec are fine, with whichever Etag may be sent in PUT responses (before or after server modification of the entity). However, given that the choice seems to be open still, I side with those who reckon sending the Etag corresponding to the entity _before_ modification by the server, just because it seems more consistent with the meaning of Etags. -- Jamie
Received on Thursday, 14 September 2006 14:30:08 UTC