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: Mark Nottingham <mnot@mnot.net>
Date: Mon, 4 Feb 2008 18:40:52 -0800
Cc: Julian Reschke <julian.reschke@gmx.de>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Message-Id: <7B449C2B-23DE-4246-9B47-6F3248CD4D9B@mnot.net>
To: Yves Lafon <ylafon@w3.org>

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.

On 31/01/2008, at 7:14 AM, Yves Lafon wrote:

> On Thu, 31 Jan 2008, Julian Reschke wrote:
>>> Should we keep this "multiple locations for one resource" paradigm?
>> First of all, I do not agree with the "single new resource"  
>> interpretation. As Brian observed, that would be a conflict with  
>> RFC5023.
> In that case, we need to amend the current text as I read it as  
> implying there is only one new resource.
> Also:
> <<<
>   A 201 response MAY contain an ETag response header field indicating
>   the current value of the entity tag for the requested variant just
>   created, see Section 6.1 of [Part4].
> Should be:
> <<<
>   If one single resource is created, a 201 response MAY contain...
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>        ~~Yves

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 5 February 2008 02:41:04 UTC

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