On Nov 13, 2009, at 4:16 PM, Brian E Carpenter wrote: > On 2009-11-14 12:57, Roy T. Fielding wrote: >> On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote: >>> I wasn't involved in reviewing RFC2616 (or in the original design of POST, >>> even though it happened about 20 metres from my office at that time). But >>> yes, POST also lacks transactional integrity. Incidentally, that recently >>> caused me to donate twice as much as I intended to the relief fund for >>> the tsunami in Samoa, although the direct cause was a network glitch. >> >> That doesn't have anything to do with POST lacking transactions. >> Any server is fully capable of detecting repeated transactions >> just by looking at the data sent. > > Not in this case. The service was instantiated once, received > a legitimate series of POSTs, including the final one triggered > by a SUBMIT button, and then the final response code to the client > (a standard browser) vanished, for whatever reason. [Digression > about why this failure was probably caused by a NAT deleted.] > The human client simply sees a browser timeout and has no possible > way of knowing whether the SUBMIT executed. As it turns out, my credit > card bill later showed that it did. Yes, and that is exactly what would happen even if HTTP supported full two-phase commit, with all of its painful consequences, if the response to commit was lost. This is an application problem, not a protocol requirement. It can be "fixed" (to the degree that any fix is possible in a distributed system) by providing the client with a status resource within the same page as the SUBMIT, such that the client can see the change in server state when it takes place even if the specific 200 response is lost. In other words, provide the client with the information necessary to check the bill before the final transaction is submitted. > ... > Given that HTTP took the stateless approach that it did, > I don't expect the protocol to embed transactional integrity. > But I do expect the protocol spec to describe in normative terms > how to detect a relatively likely type of failure. I agree > that whether that is needed depends on the use case for PATCH. The use case for PATCH is requesting relative state changes to a known resource. The way to detect the resulting state of the resource in case of communication error is to perform a GET (perhaps with Range) on the same resource. That is one of the few benefits of defining PATCH instead of just reusing POST. ....Roy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf