W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: New "200 OK" status codes, PATCH & PROPFIND

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 6 Aug 2007 13:54:02 -0700
Message-Id: <526E92EA-24B8-45C8-A3B7-0B9D0F2545BD@gbiv.com>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

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  
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  

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.

Received on Monday, 6 August 2007 20:54:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC