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