- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 6 Aug 2007 13:54:02 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
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. What might differ is the etag of the entity that would have been retrieved via a GET resURI, where resURI != propURI, since the GET resURI etag is actually a value within the properties of resURI and only needs to change when the content of the resURI entity changes, not when the content of its properties change. Did I mention that PROPFIND is evil? Properties of a resource are a different set of resources. PROPFIND is merely a GET with one level of indirection built-in, and everything in the response has to be interpreted that way or we'll all go nuts. RFC 2616 does not standardize because I was hoping that PROPFIND wouldn't exist. ....Roy
Received on Monday, 6 August 2007 20:54:12 UTC