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 13:52:12 +0100
Message-ID: <47A85BFC.7040003@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:
>> So what kind of side effect would be updating a hit counter GIF? Or 
>> updating a list of "top referrers"?
> If the resource triggers the modification, then GET is misused, if it's 
> a server configuration (filter, automatic log analysis), then the 
> resource is not responsible for those side effects.

That seems at best fuzzy to me. The distinction you mentioned seems to 
be an implementation detail, so not really relevant...

>> 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>
> I know about the definition of Location, but here we are not 
> redirecting, just indicating the URI of the main newly created resource, 
> and it can be done by only exposing it in the response entity (there is 
> no MUST there).

Again? Why would you want to return a Location header in PUT->201? I 
don't think servers do return it today.

>>>> - 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.
> But in this case it may apply to another URI than request URI...

It should apply to the Request-URI.

BR, Julian
Received on Tuesday, 5 February 2008 12:55:57 UTC

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