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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 06 Aug 2007 23:49:32 +0200
Message-ID: <46B7976C.9040302@gmx.de>
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.

Well, that definition is not in RFC2616. Can we please agree on a 
proposed change, and add that to the resolution for 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>?

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

In which case the ETag will depend on both some request headers (such as 
"Depth"), *and* the request body. This may be a problem for some proxies.

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

Right.

> Did I mention that PROPFIND is evil?  Properties of a resource are a

I think so :-). GET-Location just is trying to make it less evil.

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

GET-Location exposes that indirection, so clients can actually do 
something better once they know it.

It seems that we all agree that it's good to give the client a URI of 
something GET can be applied to. Let's just find the best way to do that.

Best regards, Julian
Received on Monday, 6 August 2007 21:49:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT