NYCPHP Meetup

[Ophir Prusak]

I was recently tasked to fix this exact issue.
In a nutshell, our solution was simply to change "post" to "get" in most 
of our forms.

First of all, you need to check where this makes sense.

For all the forms where submitting the form would not make any changes 
to the data (only use db selects) this was fine. For example, in all of 
our search and report pages.

For all the forms where submitting the form could possibly change data, 
we chose not to change it to get, and leave the "this page has expired" 
error message. For example, if the user is inserting a new record into 
the database.

We of course had to make some other changes, both to the backend and the 
forms themselves,
The backend was quite simple, mostly changing $_POST to $_REQUEST.

For the forms themselves, it was not enough to change POST to GET.
It seems that for GET requests, the browser (at least IE 6) truncates 
anything after the ? in the action variable.
For example, if you have this:
<form action="form_test.php?other=blah" method=GET>
When u submit the form, the other=blah won't be there.
I whipped up a working example for this at 
http://www.stationplay.com/dev/form_test.php where you can see this in 
action.

Our solution was to pass in hidden variables, so it ended up being this:
<form action="form_test.php" method=GET><input type=hidden name="other" 
value="blah">

Hope that helps,
Ophir


Chris Hubbard wrote:

> All,
> What are strategies you've implemented to eliminate the "this page has 
> expired" that commonly gets displayed after a user clicks the back 
> button?
> I've seen lots of sites that use sessions, where clicking the back 
> button "breaks" the application by displaying the expired message.  
> I've seen a couple pages where clicking the back button doesn't break 
> the application.
> Hints, suggestions, thoughts?
> Thanks,
> Chris
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk