Hi, On Thu, Oct 29, 2009 at 11:29 AM, SM <sm@xxxxxxxxxxxx> wrote: > > In Section 2: > > "If the entire patch document cannot be successfully applied > then the server MUST fail the entire request, applying none > of the changes." > > I suggest rewriting the sentence: > > If the entire patch document cannot be successfully applied > then the server MUST NOT apply any of the changes and it > SHOULD return the appropriate HTTP status code as defined > in Section 2.2. I am fine with this change. >... > > In Section 2.2: > > "There are several known conditions under which a PATCH request can > fail. > > Malformed patch document: Can be specified using a 400 (Bad Request) > when the server finds that the patch document provided by the > client was not properly formatted. The definition of badly > formatted depends on the patch document chosen, but generally if > the server finds it cannot handle the patch due to the > serialization of the patch document, this response ought to be > appropriate." > > The wording is clear and I will probably follow the intent of the authors of > this draft. In terms of implementation, the "can be specified using" and > the "ought to be appropriate" does not clearly spell out what status code to > expect for the error condition. The comment is applicable to the known > conditions in the "Error handling" section. I suggest being more specific > about what the response should be. For example: > > 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. > > As an additional comment about "Conflicting modification", "Precondition > Failed" is discussed in Section 10.4.13 of RFC 2616. I see this more of a > precondition evaluated as false instead of a conflicting modification. 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. > > As an additional comment about "Concurrent modification", this looks more > appropriate as a 503 (service unavailable). > 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. Does that make sense? Lisa _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf