View Full Version : Preventing a browser refresh from reposting

04-27-2006, 12:11 AM
I've searched for solutions on how prevent a browser refresh from posting a repeat process, and a suggestion of redirecting the page to a "dummy" page which then flips back to the main page seems like something I can handle.

My problem is, I'm not quite clear on the journey. Here's what I understand:

Page loads, waits for user input
User fills out form and hits "submit"
Page inits, with $_POST variable populated with form data (I have a db_start() up top)
PHP code is processed, at which point I take care of form data

here is where I'm not sure how the redirect should happen. I'm thinking:
Before page is released to browser, I redirect the page to the "dummy" page with something like this:

$host = $_SERVER['HTTP_HOST'];
$uri = rtrim(dirname($_SERVER['PHP_SELF']), '/\\');
$extra = 'dummy.php';
header("Location: http://$host$uri/$extra");

Finally, the dummy page has a single header command to reload, sans $_POST variable, the main page.

Do I have the right idea? Or is there a better way?

04-29-2006, 01:21 AM
Do I need to rephrase this question?

04-29-2006, 08:13 AM
Your POST page should send the data to a processing page. This page should not return anything to the user-agent (users browser). It should instead redirect to another page that sends output to the user-agent.

04-29-2006, 12:40 PM
I think you're doing it well, but I think an easier and more valid way of doing this is this:

Upon posting the form, save the current time in a $_SESSION variable,

$_SESSION['posted'] = strtotime('now');// Will contain the time in seconds since January 1970

Then you can check if the user has posted within a specified limit of time,

$currtime = strtotime('now');

$prevtime = 0; // Big difference between current and previous time
$prevtime = $_SESSION['posted'];
$timediff = $currtime - $prevtime;
$limit = 500; // Time in seconds there has to be between two posts
if($timediff > $limit){

// Put your actions here


05-01-2006, 06:15 PM
hemebond-- That was the ticket, works great! thanks. Now, what mechanism would you use to send data from the processing page back to the display page? Let's say there's an error in the processing, and I need to let the user know about the error. The only thing I can think to do is use a query string on the url, but that might get messy-- especially if I am using a query string on the display page for other things already. Any other thoughts on that?

Vin0rz-- your technique worked too-- a little too well! :p I don't want to prevent a user from performing actions on the form many times quickly in succession, as long as they are legit actions-- I just want to disable the "refresh" issues, and a separate processing page seems to do the trick.

05-04-2006, 07:06 PM
Well, if the processing page did not output anything then you'd be able to send headers I guess... Or don't I understand the question?

05-04-2006, 11:27 PM
Well, if the processing page did not output anything then you'd be able to send headers I guess... Or don't I understand the question?I think he is asking on the processing page if you have php checking to see if a field is blank & it blank then it shows the page again to have the field filled in. Then when the user fills in the field & resubmits the form it wont let him because he has to wait 500 seconds to resubmit the form.

What about if we have this line $_SESSION['posted'] = strtotime('now'); right before the line that says Submission of form successfull...would that work? If we put that line above as I just stated then if the php says the field is blank & sends you back to fill in the field then the script never processed as far as to say Submission of form successfull & so the $_SESSION['posted'] = strtotime('now'); never got set...right?