Hi,
On Thu, Oct 29, 2009 at 11:29 AM, SM <sm(_at_)resistor(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf