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: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 5 Feb 2008 10:19:35 +0100
Message-Id: <4444E7DC-994B-4CA0-BA13-45AB24B6AB32@greenbytes.de>
Cc: Yves Lafon <ylafon@w3.org>, Julian Reschke <julian.reschke@gmx.de>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
To: Mark Nottingham <mnot@mnot.net>


Am 05.02.2008 um 03:40 schrieb Mark Nottingham:
> I don't think that does the trick. APP creates multiple resources  
> and returns a 201 with a Location of the "Member entry URI",  
> mentioning that other resources could have been created in the  
> process.
>
> So, a 201 can imply the creation of one or more resources; if the  
> response contains metadata (e.g., Location, ETag), they are  
> associated with the most important one, in the judgement of the  
> server.

When thinking about a good wording for this, I stumble into the tar  
pit of defining "cause" and "effect" for a http application that is  
unknown. Trying to sort this:

- resource are created on a server all the time. Even a DELETE may  
create a resource, e.g. a record of the action. A PUT on an existing  
resource may do the same (implicit versioning in DeltaV). These  
actions however will not result in a 201 response.
- A 201 response is sent when the server wishes to inform the client  
that, as a consequence and in direct relevance to the request, the  
Location resource was created.
- In this light a "201" dies *not* describe a side-effect but a  
server state change that is in direct connection to the request,  
relevant for the client to know in the context of the request and  
often even the *only* possible success code for the request.
- The term "side effect" in 9.1.2 in 2616 is problematic. It has  
caused many myths about GET. A GET can have side-effects on the  
server (writing access.log, updateing statistics pages). But none of  
these side effects should be of relevance to the client, nor can they  
be expected, nor a are they reproducable. There is no statistical  
correlation between a GET and the resource changes on a server.

So,

- 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???)
- a ETag header on the response indicates the current value of the  
entity tag for this requested variant (request uri or location)


//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
Received on Tuesday, 5 February 2008 09:19:50 GMT

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