Document: draft-dusseault-http-patch-15.txt Reviewer: Brian Carpenter Review Date: 2009-11-12 IETF LC End Date: 2009-11-24 IESG Telechat date: Summary: Issue with transactional integrity -------- Comment: -------- I have not had time to follow all the Last Call comments on the IETF list. Apologies for any overlap. Major issues: ------------- As far as I can tell, the proposal places the burden for ensuring atomicity entirely on the server. However, PATCH is explicitly not idempotent. If a client issues a PATCH, and the server executes the PATCH, but the client then fails to receive an indication of success due to an extraneous network glitch (and TCP reset?), then what prevents the client issuing the same PATCH again? In other words, absent a two-phase commit, there appears to be no transactional integrity. If I have understood this correctly, PATCH is not only not safe in the RFC2616 sense, it is not transactionally safe either, so the state of the resource after {PATCH, lost response code, PATCH} is undefined. I don't believe that the non-normative words starting "Clients wishing to apply a patch document to a known entity..." are anything like enough to fix this problem. I don't know enough to know whether some normative text using ETag is sufficient (it's clear from the draft that If-Unmodified-Since is insufficient). This doesn't seem easy to fix without adding a "ready to commit"/"commit" exchange, which also needs transaction IDs (perhaps based on strong ETags) and a new state machine at each end. I'd be glad to learn that I'm missing something.