Joshua Olson <mailto:joshua at waetech.com> wrote: > ----- Original Message ----- > From: "Chris W. Parker" <cparker at swatgear.com> > Sent: Thursday, January 23, 2003 11:55 AM > And if they press the back button, what happens? Let's work through > this for a second: > > 1. page1 is in their browser history as the "current" page. > 2. they transfer to page2 for processing. page1 is one page back in > history, but doesn't have the error. > 3. ok, so we think we set a cookie > 4. depending on how you "send them back to page1" the cookie may or > may not be set. If you do a server side relocation (such as with > cflocation) then the cookie never gets set on the client machine. > 5. ... now the process is broken. Hmmm... well i'm going from my experience with asp. if i set a cookie and then Response.Redirect("page1.asp?error=this+error") iirc it will work as expected. that is, the cookie will be set even though the server relocates. but then again this is what i remember happening and can't say that for sure it will happen. > 1. The page will be pulled out of the cache and the rendered error > message will display. If this is the case, the only way to avoid > displaying the error message is to use something on the client that > executes on page display that would somehow remove the error message. > JS is one such technology that could do this. > > 2. The page will be rerequested from the server. But, since the URL > is in tact, it'll STILL come back with the error message. The only > way to do this would be to somehow let the server know it needs to > ignore the error message request. This could be done with normal > cookies/session variables. Disable cookies or session variables and > this wouldn't work. > > If you cannot dictate that scenario #2 happens, then you are > essentially stuck using client side scripting of some sort if you > intend to keep things somewhat simple. hmmm... i see what you are saying. > I'm afraid that your suggestion may not solve this problem yet. yes. thanks for the explanation. chris.