One major issue is how you want to handle BACK. You can use no cache but users expect to be able to use the back button.

I just had a great realization here. I can't believe I never really thought about users using the BACK button on their browser. I can imagine the amount of confusion and damage done with this. Besides using a param hash in a hidden field, I suppose you could use the "Cache-control: no-cache" and then keep a 'step' number/key in the database as well. This identification token could then indicate which step in the process the user is working on, and load only the page that step corresponds to, unless the parameter to change the step is sent to the script. So in a shopping cart app, after saying "I want 10 pairs of shoes", and hitting the "Add to cart" button, say I want to change it to 5 pairs. I might hit the 'back' button, but this would load the same page I'm already looking at, perhaps with a 'sorry, do it the long way around' message.

I'm not sure how efficient what I am saying would be to implement and use, so I am going to give it a whirl of a test to see how it does work out. The only downside I can come up with is huffy, puffy users who want their BACK button functionality to function the way it's supoosed to :) I'm going to put something together, and then perhaps throw it in the code catacombs or code snippets. We'll see...

-------------------------------------
eval reverse@{[lreP
=>q{ tsuJ\{qq},' rehtonA'
,q{\}rekcaH },' tnirp']}[1+1+
1,1-1,1+1,1*1,(1+1)*(1+1)];
-------------------------------------