Re: #331: clarify that 201 doesn't require Location header fields

On 2012-03-09 10:16, Julian Reschke wrote:
> On 2012-03-08 01:41, Mark Nottingham wrote:
>> Maybe I'm nitpicking, but I'd like to see it be more general; i.e.,
>> other methods could, in theory, be defined to use 201 without a
>> location (although I'd grant this is unlikely).
>>
>> It's also a bit wordy, currently.
>>
>> Suggest:
>>
>> """
>> 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).
>> """
>> ...
>
> I like this better, but it makes another change (talking about multiple
> resources being created) that we haven't discussed before; I believe
> this should go into a separate issue...
>
> Rephrased proposal:
>
> 7.2.2. 201 Created
>
> The request has been fulfilled and has resulted in a new resource
> being created.
>
> The newly created resource is 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).
>
> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/331/331.2.diff>)

Hearing no objections: <clarify that 201 doesn't require Location header 
fields>

I have also created 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/347> to track the 
other issue (more than one resource being created).

Best regards, Julian

Received on Saturday, 10 March 2012 12:34:33 UTC