It sounds like you need to rework your logic. You can *reduce* caching of pages using headers, but browsers are free to (and do) ignore these. See Control of cache and overkill anti-caching CGI headers. The main problem with hyper agressive anti caching is that it is very Back button (read user) unfriendly. On one of the Internet banking sites I use if you try to use back you get a blank can't refresh page. OK so you click *Forward* only to be greeted by the same thing! The >only< way out is back, back back until you get to a cached page - turns out to be the login page. Secure it may be. User friendly it is not.

There are workarounds. Evidently you must be storing a sessionID in a hidden field on the page. If you additionally (or only) used a cookie (also storing the sessionID) you can detect and correct this issue as you will have the current sessionID when the user submits their addition to the cart - this must and always will hit the server. 90%+ of clients will be allowing cookies. Many shopping sites insist on cookies as they allow users a lot more freedom and simplify maintaining state. With session cookies a user could add an item, go to their bank, check their balance, return, add more items to the still current cart and then checkout. You just can't do that with hidden field sessions. You do need to timeout the sessions of course, and only make a new session when required.