- From: Gregory J. Woodhouse <gjw@wnetc.com>
- Date: Thu, 19 Sep 1996 00:53:57 -0700 (PDT)
- To: Daniel DuBois <dan@spyglass.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
It seems to me that the issue here isn't really idempotence as it is a form of transaction processing. The reason we want POSTs to be idempotent is so that they can be safely repeated, presumably because the first attempt may or may not have failed. I have mixed feeling here because transaction processing is obviously at odds with the "stateless" model of HTTP. But, on the other hand, forms are commonly used as database frontends, or as interfaces to other programs which do have side-effects. Off-hand, it seems that something like the cookie mechanism could be used to implement a transaction scheme. The key is that the client needs to be able to accept data (a transaction ID) from a response header, or even a response with a MIME type which signals that the data should not be displayed but stored temporarily. The following scenario indicates how this might work (but see my comments below): 1. The client POSTs some data. 2. The server accepts the data and places it in temporary storage. 3. The server then returns a response which includes a transaction ID. 4. Upon receiving this response, the client sends a separate COMMIT request which includes the transaction ID. 5. The server then saves off any necessary state information so it can restore its original state if the transaction fails. 6. It then attempts to complete the transaction (e.g., database update) and waits for confirmation of success or failure. 7. Upon failure, it restoresits state and then returns either success or failure to the client. 8. Upon failure, the client re-POSTs the data, accepts a new ID, etc. 9. Upon success, it returns to the user with an indication that the POST was successful. Obviously, this scheme needs to be refined because it is possible that the COMMIT would succeed, but then the response indicating success would be lost. So, the above algorithm really needs to be replaced by a two phase commit. The advantage to this scheme is that on the one hand it requires no user intervention, and on the other if the server doesn't recognize (from the request header) the request for a transaction, this scheme will fall back on an ordinary POST. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/
Received on Thursday, 19 September 1996 00:58:57 UTC