I can give you the definitive answer on this after much research. It is caused by the following:
1) The user submits a form as a 'post' 2) The browser displays the results of the post 3) The user goes to another page 4) The user hits the back button to return to the results page from the post 5) The browser has dropped the page from its cache 6) Wisely, the browser asks you if you would like to re-post the form vars that generated the results page. If it automatically did this for you, it could trigger repurchases and all other kinds of mayhem. The simplest solution to this is to change your form to 'get' instead of 'post'. This will cause the browser to change all of your form vars to url vars on the fly. Thus when the user hits the back button, if the page is no longer cached the browser will reload it without issuing the workflow-killing refresh error because there is assumed to be no chance (by convention) of danger. This solution is quite simple and is employed by ebay. The only limit I know of is url length, which I found to be for IE 6 about 1250 characters (I forget the exact figure). There is another way to approach this, to use a javascript trick to try to change order of the results page in the browser's history so that it gets confused and will re-post the form without asking permission. I haven't tried this and I can't speak to whether or not it works. So, the reason why this intermittent plague of non-cached form results happens is related to either 1) the browser version of the user and when it decides to purge its cache, or 2) the headers and/or meta tags returned by the server which help it make that decision. While some browsers give this error 100% of the time, others do it every now and then, and typically longer into a browsing session. My assumption is that MX has a different header which is causing a different action by the browser, although you might have just changed out your browser without realizing it. For reference, Netscape and Mozilla have this behavior, too. It is the natural and correct behavior once the cache has been purged. The optimal solution is getting the browser to always cache *your* server's pages, but killing the error is the second best option. To research further yourself, search in google groups with the text of your warning. There are hundreds of people asking this very same question. Matt -- Matt Wisdom CTO Turbo Squid > -----Original Message----- > From: Brian Scandale [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 7:39 PM > To: CF-Talk > Subject: CFMX caching... > > I switched to CFMX a few days ago... > > Suddenly (when clicking back) Many pages declare the Warning: Page has > Expired. The page you requested was created using information you submitted in a > form. This page is no longer available. > > To resubmit your information and view this Web page, click the Refresh button. > > -------- > This is NEW behavior in just the last few days and I am having trouble tracking it > down. > > I have pulled out all the META caching tags like: > > <!---<meta http-equiv="Pragma" content="no-cache"> > <META HTTP-EQUIV="Expires" CONTENT="-1">---> > > but I am still getting all the Warnings. > > Prior to CFMX I had no problems backing up across the pages... Anyone know > what might be doing this? > > Thanks, > Brian > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
