- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 27 Feb 2008 10:22:30 +1100
- To: Subbu Allamaraju <subbu.allamaraju@gmail.com>
- 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>
I'd be OK with adding a non-normative example, at the most; adding normative language for this would imply that we're defining a sever- side model for how HTTP should be implemented, which (as Roy has pointed out several times), isn't a good idea. Cheers, On 26/02/2008, at 7:59 AM, Subbu Allamaraju wrote: > If creating multiple resources via POST is indeed a valid > interpretation of 2616, could this be clarified in the 2616bis? > > Thanks > Subbu > > On Feb 4, 2008, at 6:40 PM, Mark Nottingham wrote: > >> >> 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 > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 26 February 2008 23:22:46 UTC