RFC2616 uses similar language when referring to implementation requirements for Pipelining [1], but does not set requirements for reporting errors to the client. mca http://amundsen.com/blog/ [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2.2 On Mon, Nov 2, 2009 at 14:22, Eliot Lear <lear@xxxxxxxxx> wrote: > > > > On 10/30/09 10:27 PM, Nikunj R. Mehta wrote: >> >> On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote: >> >>> >>> Hi, >>> >>> On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta >>> <nikunj.mehta@xxxxxxxxxx> wrote: >>>> >>>> This draft places unreasonable restriction on servers about processing >>>> requests. Specifically, in §2.2, >>>> >>>> [[ >>>> Concurrent modification: When a server receives multiple concurrent >>>> requests >>>> to modify a resource, those requests SHOULD be queued and processed in >>>> the >>>> order in which they are received. If a server is incapable of queuing >>>> concurrent requests, all subsequent requests SHOULD be rejected with a >>>> 409 >>>> (Conflict) until the first modification request is complete. >>>> ]] >>>> >>>> RFC2616 describes the above status code (409) but not in the context of >>>> a >>>> particular type of HTTP request. I fail to see why this draft has >>>> mandated >>>> specific error codes and specific server behavior in response to certain >>>> requests. It curtails server behavior without a good reason. >>> > > I won't speak to a specific error code, but it's fairly clear that what the > authors are attempting to do is provide for a minimum of chaos when > concurrent PATCHes are requested. These operations are meant to be atomic > in spirit if not in word. You can't have two atomic operations on the same > object at the same time. > > Eliot > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf