Re: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

The draft doesn't describe the reason for mandating specific error
handling, but the reason is to let clients handle some error cases
automatically, or at least help users make sensible choices rather
than just show "FAIL".  Also,  I'll note that another review of this
document posted just yesterday makes the opposite request, asking that
the error handling responses be more specific and constrained (SM's
review).

This is clearly a tradeoff between server flexibility and client's
being able to know what to do, so let's look at whether a client can
actually do something with the information.  In the case of a
concurrent patch, if the client knows that something else is going on
with the resource right now, it can wait a few seconds and see if the
resource has changed, then try to recalculate the patch based on the
new resource if that's appropriate.  It may be possible for the client
to resubmit the patch automatically depending on the patch format and
use case.  Even if the patch can't be resubmitted, it's possible for
the client to explain to the user what happened.

Since the requirement is a SHOULD, there is an escape clause for the
server to retain flexibility if it needs to, at the cost of having
behavior that is less predictable and manageable for the client.

Can you live with that?

Lisa
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]