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(_at_)cisco(_dot_)com> 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(_dot_)mehta(_at_)oracle(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf