![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.