W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: #347: clarify that 201 can imply *multiple* resources were created

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 21 Jun 2012 22:38:40 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7F54923F-0408-4935-998C-46AA3ADE3BFA@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
Looks good to me.

On 21/06/2012, at 6:39 PM, Julian Reschke wrote:

> On 2012-06-21 08:46, Julian Reschke wrote:
>> On 2012-06-21 05:20, Mark Nottingham wrote:
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/347>
>>> 
>>> Proposal is to replace
>>> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.201>
>>> with:
>>> 
>>> ""
>>> The request has been fulfilled and has resulted in one or more new
>>> resources being created.
>>> 
>>> Newly created resources are typically linked to from the response
>>> payload, with the most relevant URI also being carried in the Location
>>> header field. If the newly created resource's URI is the same as the
>>> Effective Request URI, this information can be omitted (e.g., in the
>>> case of a response to a PUT request).
>>> 
>>> The origin server must create the resource(s) before returning the 201
>>> status code. If the action cannot be carried out immediately, the
>>> server should respond with 202 (Accepted) response instead.
>>> 
>>> A 201 response may contain an ETag response header field indicating
>>> the current value of the entity-tag for the representation of the
>>> resource identified by the Location header (see Section 2.3 of [Part4]).
>>> """
>>> 
>>> Comments?
>> 
>> Sounds good with s/mayshouldmust/MAYSHOULDMUST/ (I assume that was a
>> copy/paste problem...)
>> ...
> 
> Full text:
> 
> 4.4.2.  201 Created
> 
>   The request has been fulfilled and has resulted in one or more new
>   resources being created.
> 
>   The newly created resources are typically linked to from the response
>   payload, with the most relevant URI also being carried in the
>   Location header field.  If the newly created resource's URI is the
>   same as the Effective Request URI, this information can be omitted
>   (e.g., in the case of a response to a PUT request).
> 
>   The origin server MUST create the resource(s) before returning the
>   201 status code.  If the action cannot be carried out immediately,
>   the server SHOULD respond with 202 (Accepted) response instead.
> 
>   A 201 response MAY contain an ETag response header field indicating
>   the current value of the entity-tag for the representation of the
>   resource identified by the Location header field or, in case the
>   Location header field was omitted, by the Effective Request URI (see
>   Section 2.3 of [Part4]).
> 
> (note that the last paragraph needed tuning so the PUT->201 special case is handled as well).
> 
> -> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/347/347.diff>
> 
> Feedback appreciated, Julian

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 21 June 2012 12:39:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 June 2012 12:39:24 GMT