[thelist] Back button issue with QueryString

Joshua Olson joshua at waetech.com
Thu Jan 23 12:21:00 CST 2003

----- Original Message -----
From: "Chris W. Parker" <cparker at swatgear.com>
Sent: Thursday, January 23, 2003 11:55 AM

> michael,
> joshua's idea is pretty good. however it's not impossible to do without
> javascript like joshua said.
> 1. submit form on page1 to page2
> 2. process form from page1 on page2
> 3. set a cookie on page2 stating that a message has not been displayed.
> Response.Cookies("errordisplayed") = "no"
> 4. send them back to page1 with the error querystring
> 5. check the cookie before any output is written to the page. if the
> cookie is "no" rewrite the cookie to be "yes" and continue with normal
> processing, if the cookie is "yes" don't process the error but instead
> display the page as it would normally appear.
> 6. kick up ya shoes and relax your feet, party on down to the xscape
> beat.

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...

Chris, it may be possible that the scenario wasn't clear 100%.

The user is ALREADY at a page that has two elements we are concerned with.
1.  The error message as directed by the url, 2.  A form the user needs to

If the user submits the form, they will inevitably end up on another page
somewhere.  The page they just submitted from is still in the history,
complete with the URL and rendered HTML of the error message.  If they hit
the back button, one of two things 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.

I'm afraid that your suggestion may not solve this problem yet.


More information about the thelist mailing list