Method=POST, Page Expired - Tried everything (?)

sholodak

Hi,

I'm working on a survey script in PHP. It collects data via standard HTML forms, submitted via POST over HTTPS for security purposes (i.e., I can't switch to GET). Users are unable to use the back button. The application is 1 script -- index.php. This script includes a header, content page, and footer in response to survey data posted (from UI form fields) and hidden form fields (maintains SessionID, passes Section in). The script stores the users data, fetches the jump logic for that section, determines what the next page of the survey, dumps that page, and the process repeats.

Users are unable to use the Back button on their browser because the page has expired. I have been unable to prevent this using any combinations of the statements below:

$cachetime = 10800; # 3 hours

$gm_expires = gmdate('D, d M Y H:i:s', time() + $cachetime);

header("Cache-control: private, max-age=$cachetime, pre-check=$cachetime"); #Except for pre-check, this is what I had

header("Cache-Control: private");

header("Cache-control: must-revalidate");

header("Expires: $gm_expires GMT");

header("Expires: " . gmdate("D, d M Y H:i:s \G\M\T", time() + 1000));

header("Last-Modified: " . gmdate("D, d M Y H:i:s \G\M\T"));

header("Last-Modified: " . gmdate("D, d M Y H:i:s \G\M\T", time() + $cachetime));

Naturally, I didn't ever use any two of the same headers at the same time, but I did try every possible combination of Cache-control, Expires, and Last-Modified shown here. I also screwed around with the Pragma header and tried a few of those as well.

I even screwed around with the Session_Cache_Limiter function

I suspect that this might have something to do with the fact that the entire survey is handled by 1 PHP script with the same URL at every step (nothing is appended to the URL, all data is handled via POST). The target of every single form is index.php. Why this should be a problem is not clear to me, but it's one of the last remaining hypotheses that I have.

Anyone have any ideas? Remember, I can't switch this to GET mode due to the confidential nature of the data & the HTTPS requirements.

I did notice that my browser is sending the following header to the web server, although I don't understand why/how/what it means: Cache-control: no-cache ... I assume this has something to do with server-side caching, which I don't think is related to the problem. I just need the client to remember the form data that was just posted so they can use the BACK button and change their responses without having to refresh.

Thanks in advance,

Scott

Merve

Sometimes pages expire for security reasons. Try not using https (maybe I'm stupid for saying this).

swr

It is recommended that POST be used for actions that may cause some "side effect" to occur (like mailing a form or submitting a sale), while GET be used for actions without side effects (like simply displaying a page).

This recommendation has influenced web browsers. They will generally refuse to re-submit POST data on the grounds that you don't want to be double-submitting and causing multiple emails to be sent, multiple sales to be submitted, etc. I think this is why you are getting "page expired".

I'm not sure how to avoid your problem, short of switching to GET method. What you might want to try, is instead of issuing settings to prevent caching (which is what most people do when they are issuing cache directives), instead you should allow caching. That might allow the browser to re-display the page without having to re-submit the form data (which it doesn't want to do).

sholodak

Merve: I have been developing without using HTTPS, so that is not the problem.

swr: you are definately on the right track as far as caching goes. What I am trying to do is get the browser to not bother even contacting the server, just to take the most recently [locally] cached version of the page and display it back to the user.

I have both seen this done before, and actually done it before, though for the life of me I can't figure out where or how. The end result is that when you hit the back button, not only do you see the last page, but all of the form values that were submitted re-appear (radio buttons & checkboxes, textboxes, etc., are populated with what was sent to the server).

The application was designed with attention to the possibility of re-submitting the same data. The data is simply stored in the database and there are no side effects. In other words, hitting submit 3 times really quick wouldn't make a difference with respect to the data in the database.

===

I think it works now. Whether this is the fix, or it was just my browser that was malfunctioning, this is the winning combination:

$cachetime = 10800;
$gm_expires = gmdate('D, d M Y H:i:s', time() + $cachetime);
header("Last-Modified: ".gmdate("D, d M Y H:i:s \G\M\T", time()));
header("Cache-control: public, max-age=$cachetime, s-maxage=0, must-revalidate, pre-check=$cachetime");

header("Expires: $gm_expires GMT");

I scrapped everything and went back to the HTTP/1.1 RFC. I gathered from there that this was a good way to go, and it works perfectly on my web browser at home (although I suspect my work computer is still not working).

It seems to make sense... The page was last modified the instant it is generated. It has public cache control where clients expire after 3 hours, proxy caches expire immediately. For redundancy, the expires header defines the exact time at which the browser should discard the copy.

Hrmph. Any ideas what might be wrong with my browser(s)? Internet Explorer 6.0 SP-1 and/or NetCaptor

Scott

orionblue

Scott had you had any luck with your problem? I'm having a similar issue, I am using <a href="javascript:history.go(-1);"> to go back to paginated search results that are generated using 'POST' but then re-cycled for pagination using 'REQUEST'... I too have tried modifying headers to get rid of the expired page warning, no luck. Any one have a new suggestion?

dave420

The browser is actually doing this on purpose (for very good reasons). If you want the effect you're after, do this:

Once the data has been posted, on the page that receives the post, at the end issue a header("location: this_page.php") and exit. Then, in this_page.php load the values posted and display them. That way, the browser will go back to that page (as no data was actually posted to it - it was posted to the page that transferred you there).

orionblue

Thanks dave420, I'm not sure that I understand what is happening here though -

form.php sends $var to results.php?page=1 (or does it send only to this_page.php? and if so, how do the variables get pulled for the search query which happens on results.php?)

results.php?page=1 displays all output, then before closing:

header(location:this_page.php); ?>

this_page.php has <?=$_GET['$var'];?> on it...

So when i leave the page, I can go back to it because the form passed the values on to this_page.php, and not on to results.php?page=1 or 2 or 3 etc., while results.php?page=1 etc would always be able to pull the $var with $_REQUEST, right?

IE wouldn't let me go back to this_page.php though, if I were to try - right? haha, i think i have just completely re-worded what you said, i'm sorry, but I would really like this to work so I need to understand how to do it!

dave420

hehehe - let's see if we can get this sorted 🙂

You display a form to the user
The form is posted to a script.
The script processes the data and displays nothing. Instead it uses header("location: this_script.php") to bounce the user back to the page (but without posting data, so the user can return)
The this_script.php page can show what the user submitted or whatever - the main thing is the browser knows you didn't post anything to that page, so it'll let you go back there. If the page auto-populates the fields, they can go back and edit them to their hearts desire, and it'll never ask to re-send data.
[/list=1]

Let me know if that either made sense or confused you 🙂 I'll do my best to help

orionblue

is there a dunce cap emoticon here somewhere ?? The confusion is for sure on my end...

Thanks for being so quick to respond, I'm going to give it a go and see how I do - I'll let you know!

dave420

Let me explain what's causing this problem.

Your browser, when you tell it to go to a page in its history that you posted data to (like a form action), it will ask you if you want to resubmit the data (so you get the same page you did the first time). To get round this, the page that has the data posted to it can use the header("location:") thing to effectively update the page in the browser's history to one that you didn't post data to. That page could be the same script (which could act differently if no post data was sent). You'll see that when you go "back" to a page like that, it'll just display. I use this technique all the time on loads of websites, and it works a treat.

orionblue

ok, I think I've grasped the concept - execution is a bugger though.

I used 'post' to send three variables via a form - $name, $min, $max - to 'search_results.php'.

'search_results.php' previously contained the following code:

$limit=$_REQUEST['limit'];
	if (!($limit)) {
		$limit = 10;
	} // set results per-page.

$page=$_REQUEST['page'];
if (!($page)) {
	$page = 0;
} // set page value. 

$name=$_REQUEST['name'];
$min=$_REQUEST['min'];
$max=$_REQUEST['max'];

if ($name=='all names') { 
	$numresults = mysql_query("SELECT * 
								FROM hr_cats 
								WHERE hr_price 
								BETWEEN '$min' 
								AND '$max' 
								AND hr_active='1'"); // the query if all are selected.
	$numrows = mysql_num_rows($numresults); 

//MORE PAGINATION CODE excluded here//

if ($areas=='all areas') {
		$results = mysql_query("SELECT * 
								FROM hr_cats
								WHERE hr_price 
								BETWEEN '$min' 
								AND '$max'
								AND hr_active='1' 
								ORDER BY hr_price ASC 
								LIMIT $page, $limit"); 
while ($data = mysql_fetch_array($results)) {

Then php is escaped to straight html that displays the results, <?=$data['hr_price'];?> until the end where I added:

header('location:theheaderscript.php'); ?>

I stripped the above code from the results page and placed it on 'theheaderscript.php' but when i searched, no results were displayed - the page displayed with nothing but the empty html layout.

Have I gone in the wrong direction or am I getting close? Again, I really appreciate your help dave420.

dave420

This method works on the following idea - the page you post to stores the information on the server somehow. It could even store it in a session or cookie if needed. Once it's done that (without displaying anything - this script is essentially dumb) it does the header() part. That needs to be done before anything is outputted, as it only works then.

When I use it, the script the form posts to just writes everything it needs to in the database, then uses the header() to jump to the same page, but which displays what was posted. That way, you can click back to it, and the browser just shows it. It doesn't ask to re-post the data.

orionblue

:: only after being stored in a db, session, or cookie ?

When I use it, the script the form posts to just writes everything it needs to in the database, then uses the header() to jump to the same page,

:: the same page == the script page (header direction), which is a different page than the display page?

but which displays what was posted. That way, you can click back to it, and the browser just shows it. It doesn't ask to re-post the data.

I think I'm going to break from this for a bit and clear my head, I'm obviously not picking this up properly. I do thank you though, I'm sure it is an awesome way of doing this but I'm goign to have to play w it for a while before getting the hang of it.

thanks again dave420.
😉

uscMarty2

This is way out there, but let me offer a different theory, one that I am still trying to nail down. I too am passing variables via post, and if all values aren't filled in, I include the page the form data came from and stick the values back into the form so the user can finish what they forgot.

On prod server (which is SSL, btw) everything works perfect if the form is incomplete. However, once all data is entered, the script still errors but does not pass the form data, rendering a blank form with no values. Better yet, if I refresh this page the correct data is then passed and the script functions as normal.

Sounds like a caching issue, right? I barked way up that tree, as you are doing now. Server admin assures me no caching is taking place, given that it is SSL. He also was unable to replicate my issue.

I also noticed that this problem was not consistent accross all computers.

In an un-related issue with IE, I decided to do a repair of the browser. I picked the wrong thing from add/remove programs and un-installed the latest hotfix.

Just found this link, VERY INTERESTING!
check it

This refer's to the latest update bringing some web-apps to a screeching halt! I might actually have a valid point in this post.

The fix addresses passing credentials through the url, but it also touches on SSL sites being compromised as well. MS screws us again.

sholodak

I ran into the same problem again on another project and this thread came up on Google... I realize about a year has past since I last posted on this thread, but at least this time I have some more insight on the situation.

Firefox and IE behave the same way and I have almost completely concluded that the behavior is caused by the use of HTTPS.

I am pretty sure that the problem stems from the fact (?) that these browsers don't cache pages which were transferred over an SSL connection, though they do seem to be caching the POST data (at least until you close your browser). So when I submit a form and hit the Back button, the browser searches the local cache and doesn't find the page. The only option at that point is to resubmit the form using the cached POST data.

-Scott