W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 05 Feb 2008 12:13:59 +0100
Message-ID: <47A844F7.5040309@gmx.de>
To: Yves Lafon <ylafon@w3.org>
CC: Stefan Eissing <stefan.eissing@greenbytes.de>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>

Yves Lafon wrote:
> I agree that even a GET might have side effects, but no "direct" ones. 
> By "direct" I mean relative only to the processing of the HTTP request 
> by the resource. ie: doing a GET on a resource X may generate a log 
> entry (and this log entry may be addressable), but it's a global server 
> action not a resource one.

So what kind of side effect would be updating a hit counter GIF? Or 
updating a list of "top referrers"?

>> - a 201 response informs the client that "a" resource has been created 
>> (maybe more)
>> - a Location header informs the client of the URI of this new resource 
>> (if missing the URI is the one of the request???)
> 
> As the URIs should be in the entity of the response, the logic of 
> !Location => request URI is wrong.

Disagree. Why would you send a Location header for a successful 
(initial) PUT to a URI? Remember:

"The Location response-header field is used to redirect the recipient to 
a location other than the Request-URI for completion of the request or 
identification of a new resource." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>

>> - a ETag header on the response indicates the current value of the 
>> entity tag for this requested variant (request uri or location)
> 
> How does an ETag sent with a 201 differs from one sent with a 200 and a 
> Content-Location?

It should never differ, and only depend on the Request-URI + those 
request headers that select the variant.

> ...

BR, Julian
Received on Tuesday, 5 February 2008 11:14:23 GMT

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