- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 08 Dec 2005 21:50:24 +0100
- To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- CC: Jim Whitehead <ejw@soe.ucsc.edu>, Lisa Dusseault <lisa@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>
Wilfredo Sánchez Vega wrote: > ... > Yes, but it would also be achieved if a strong ETag was delivered > during the first second (including on PUT). Use of a weak ETag doesn't > help with that, as far as I can tell. But with the current algorithm, the server can't return a strong ETag, unless it blocks updates of that content for one second. That may be unacceptable for some resources. > ... >> I think I disagree here. A few days ago I asked about this on the HTTP >> mailing list, and the consensus seems to be: >> >> - just because a server accepts a PUT and returns a (strong) ETag >> doesn't mean that it didn't rewrite the contents >> >> - the ETag is *not* for the entity body returned with PUT, but for the >> entity you would get upon a subsequent GET/HEAD >> >> - and yes, RFC2616 needs to be clarified >> >> (see thread >> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/thread.html#13>) >> > > Consensus on that thread seems to be that a ETag on PUT should be the > ETag you'd get on a subsequent GET. I don't see any discussion about > strong vs. weak and whether changing from strong to weak and back is a > good idea, which is, I think the point that Jim was making. Yes, that question wasn't asked over there. >>> OK, that's a vote for "the weak etag is wrong". >> >> My take is that the current drafts requirements for strong ETags and >> for ETags returned upon PUT are questionable. I think it has been >> demonstrated that >> >> 1) in some cases, weak ETags are just fine, and that >> >> 2) a requirement to return an ETag upon PUT will *need* to also >> clarify what that means >> >> The latter optimally would be an erratum to RFC2616, which well >> require a discussion over on the HTTP mailing list, with proposed text >> changes and consensus among the readers of the list (I'm *not* >> volunteering to do this because of other priorities). > > I'm not sure why you think the requirements for strong ETags in the > current HTTP spec is a problem. I agree that clarification on the I was talking about the current version of RFC2518bis... Best regards, Julian
Received on Thursday, 8 December 2005 20:52:27 UTC