Re: I-D ACTION:draft-reschke-http-get-location-00.txt

Henrik Nordstrom wrote:
> On tis, 2007-07-31 at 22:37 +0200, Julian Reschke wrote:
> 
>> I think that's one of those unresolved issues, remember that other draft?
>>
>> RFC2616 states:
>>
>> "The ETag response-header field provides the current value of the entity 
>> tag for the requested variant."
>>
>> So what would returning ETag on an empty PUT response mean in this case?
> 
> You mean in a 204? It's quite well defined imho.

What if it's a 200 and the entity said "PUT request succeeded"?

> And in this case it's even more well defined. The 207 response IS the
> requested variant, and is the same as the 200 response to the other
> location.

Last time we discussed this at length (something like 18 months ago), 
the consensus was that "the request variant" is what you would get if 
you would send a GET request with the same set of headers.

PROPFIND, after all, does *not* return a representation of the resource 
at the Request-URI.

Maybe we should focus on 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>, then?

> ...
>> Well, but the resource you send PROPFIND to is a *different* resource 
>> from the one you get an URI for in GET-Location. Otherwise, you could 
>> have used GET to retrieve the properties in the first place, right?
> 
> Well, when you have learnt the URI then you can. As demonstrated by your
> second If-None-Match example in A.1.

Yes.

> Content-Location is a property about the response entity, not the
> resource processing the request.

Yes, indeed. Looking at what I actually wrote about this in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-get-location-latest.html#rfc.section.B.2>:

----
Section 14.14 of [RFC2616] states:

     The Content-Location value is not a replacement for the original
     requested URI; it is only a statement of the location of the
     resource corresponding to this particular entity at the time of the
     request. (...)

However, the purpose of "GET-Location" is to enable the server to 
provide a permanent replacement URI.
----

> ...

Best regards, Julian

Received on Wednesday, 1 August 2007 00:08:18 UTC