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

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