- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Aug 2007 14:25:30 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Roy T. Fielding wrote: > > On Aug 6, 2007, at 1:21 PM, Julian Reschke wrote: >> Roy T. Fielding wrote: >>> ... >>>> 210 Information returned >>> No way. That is what Content-Location provides. We don't need a >>> Content-Etag header field -- the Etag response header field would >>> always have the same value. >> >> I have to disagree here. This is not what RFC2616 says, which defines >> the Etag in terms of the "requested variant". Let's clarify this one >> first! > > I already defined it, and yes it says the same thing. The requested > variant is the same whether the method is GET propURI or PROPFIND resURI. > If an etag exists for the properties, it is going to have the same value > whether those properties are retrieved via GET propURI or PROPFIND resURI. I agree that that definition (as seen in <http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0199.html>) makes sense, although to make it work with PROPFIND/SEARCH/REPORT it would also need to include the request *body*. However, I'm not 100% sure there's consensus for it. The major change here is that it takes the request method into account. Code that relies on it being method agnostic would break. (Such as a PROPPATCH with an If-Match header using a cache validator previously returned in GET). > ... Best regards, Julian
Received on Tuesday, 7 August 2007 12:25:56 UTC