I am no master of the http protocol. It is very interesting that you have isolated everything down to the CF 5 and CF MX servers. How different is the actual html file -- just a little whitespace? I expect that this can't be the cause.
It has to be some difference in the http communication itself, which leads me to think that it is not curable. Here is a tool called TracePlus32 Web Detective 2.20 on download.com that can be used in demo-mode and may help. http://download.com.com/3000-2068-10110784.html?tag=lst-0-1 "TracePlus32 Web Detective is a trace/analysis tool specifically designed for Web development. The Web Detective decodes the HTTP protocol and displays it in an easy to understand format." Running a side by side analysis might give us some answers. Even still, I'd be willing to bet some users of your site had this problem, it just wasn't 100% of the time. At our company, maybe 3 people have it 100% and 3 people never, and 8 people intermittently. Matt -- Matt Wisdom CTO Turbo Squid > -----Original Message----- > From: Brian Scandale [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 10:28 PM > To: CF-Talk > Subject: RE: CFMX caching... > > At 07:12 PM 7/9/02, you wrote: > >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. > > Yes... I understand the above... I only put the javascript:history.back(); in places > where it makes sense to use it. > > The problem is repeatable ... the EXACT same code using the EXACT same > computer & browser against CF5 does not ask to repost while against CFMX it > does. > > Looking at the headers shows them to be IDENTICAL... unless you are referring to > header information that is not displayed using ViewSource. > > I'm WAY stumped. > > > >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). > > Could work on some pages... Unfortunately some forms hold 100 plus hidden > fields. > > > >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. > > Interesting... but would rather just find the cause and set the appropriate switches > to make it stop happening. > > > > >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 > >> > >> > >> > > > ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.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
