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

From: "Nikunj R. Mehta" <[email-masked]>
Date: Fri, 30 Oct 2009 14:27:11 -0700

On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote:

>
> Hi,
>
> On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta
> <[email-masked]> 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?

As I explained in my message, even a SHOULD is not a valid  
requirement. I think that no HTTP method has this kind of a  
requirement and I don't see PATCH as requiring it.

Nikunj
http://o-micron.blogspot.com

---

From: SM <[email-masked]>
Date: Mon, 02 Nov 2009 11:10:33 -0800

Hi Lisa,
At 10:07 30-10-2009, Lisa Dusseault wrote:
> >   Malformed patch document:  When the server determines that the patch
> >      document provided by the client is not properly formatted, it SHOULD
> >      return a 400 (Bad Request) response.  The definition of badly
> >      formatted depends on the patch document chosen.  If the server
> >      finds it cannot handle the patch due to the  serialization of the
> >      patch document, this response is appropriate."
>
>I am fine with this change too.

I'll comment on other parts of Section 2.2.

>In HTTP, "Precondition Failed" means something very specific, that
>there was a precondition header supplied by the client, and evaluating
>the client's precondition failed.  It would confuse a client to send a
>precondition header that would succeed but this response was returned
>anyway, or for a client to send a request with no precondition headers
>that failed with this response.

That's what I meant.  The "whose state has changed since the patch 
was created" in that paragraph may not be as clear to the reader as 
what you said above.

>To me, using 503 implies a longer-term or less-well-understood issue.
>There are lots of reasons a server could return 503 and the right
>response for the client would not normally be to retrieve an updated
>resource.  For both uses of 409 Conflict in this specification (both
>conflicting and concurrent modification scenarios), one sensible
>client action would be to tell the user that the resource may have or
>has changed, to download the changed rseources, and possibly to try to
>re-apply the user's requested changes to the modified resource.  For
>503, that reaction would not be indicated.

I read the last sentence in that part (Concurrent modification) as 
hitting resource limits.  From what you said above, it looks more 
like the server not capable of
queuing concurrent requests.  The 409 Conflict is appropriate then.

I'll follow up off-list as these are minor nits.

Regards,
-sm

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Nov 2009 20:22:37 +0100

On 10/30/09 10:27 PM, Nikunj R. Mehta wrote:
>>> This draft places unreasonable restriction on servers about processing
>>> concurrent requests, all subsequent requests SHOULD be rejected with 
>>> a 409
>>> RFC2616 describes the above status code (409) but not in the context 
>>> of a

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

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 04 Nov 2009 14:00:49 -0500

> requirement and I don't see PATCH as requiring it.

My reading of the proposed text is that it allows for modes of operation
not commonly seen in HTTP servers today (ordered pipelined operations).
Clearly, the addressing of resources on which this was to be supported
would have to be done carefully, but it's not hard to imagine ways of
doing it.

The proposed error code usage (specifying a particular code to indicate
potential conflicts between PATCH requests) is very helpful to the
client, since it allows for clearer error reports and potentially
automated recovery.

---

From: mike amundsen <[email-masked]>
Date: Mon, 2 Nov 2009 14:44:12 -0500

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 <[email-masked]> wrote:
>>>> to modify a resource, those requests SHOULD be queued and processed in
>>>> the
>>>> concurrent requests, all subsequent requests SHOULD be rejected with a
>>>> 409
>>>> RFC2616 describes the above status code (409) but not in the context of
>>>> a
>>>> specific error codes and specific server behavior in response to certain
> 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
>
>