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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 01 Aug 2007 02:07:56 +0200
Message-ID: <46AFCEDC.2040805@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

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.


> 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 

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC