note 16283 deleted from ref.session by sniper

Bear in mind that the use of cookie for storing the session id, is global to all open windows of client (browser). Thus it is possible to post a form from a page whose inputs do match the current state of the session, which can cause unpredictable behavior. IMO, the use of nocache by default PHP sessions, is to try to mitigate this problem, but not completely eliminate it. Also the use of cookie global to all open windows, prevents multiple simultaneous sessions per browser (each in own window). Unless you record an identifier in the POST or GET vars of the page, in which case you might as well store the session id there instead. In order to work around this problem with using cookie, pass the session id along in the POST or GET vars. Then you can turn caching back on. One can imagine the case where some incorrect values are posted from an out of sync page (window) and overwrite some crucial data in the session or worse recorded permanently to database. The use of cookie for session id is convenient but it is risky and unpredictable. From a practical view, the user may never attempt to open a 2nd window on a session, but I am not going to risk my data on that assumption. Also I would like to re-enable the Back button (caching). IMO the other weaknesses of using cookie is that you must rely on PHP's --enable-trans-id for case where cookies are off, and as of 4.0.6 this compile flag will not work in cases such as Header( Location: ), Meta-refresh, Javascript client side programmed links, etc.. Before 4.0.6, it apparently did not work with POST forms.