Re: Etag-on-write, 2nd attempt (== IETF draft 01)

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