W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: idempotence of POST

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
Message-Id: <Pine.SGI.3.95.960919001812.9460F-100000@shellx.best.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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:13 EDT