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

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 UTC