41

I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:

To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.

Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.

Basically, I would like to do it the way this page does:

http://www.pikanya.net/testcache/

Enter something, submit, and click Back button. No warning, it just goes back.

Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.

I guess it could be doable with some HTTP headers, but which exactly?

bignose
  • 30,281
  • 14
  • 77
  • 110
Milan Babuškov
  • 59,775
  • 49
  • 126
  • 179
  • Just so I make sure I know what's going on here, can you paste the text of the warning? – Peter Bailey Mar 18 '09 at 22:23
  • The page you linked does not eliminate the warning. I still see: Confirm To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier. [Resend] [Cancel] – Sparr Mar 18 '09 at 22:26
  • Not if you use Firefox 3.0.6 or a similar version. You probably have a browser where it has been "fixed". – Milan Babuškov Mar 18 '09 at 22:46
  • 2
    The browser where it is fixed for good is Opera. It does not have this dialog at all, it always resends the data without asking the user, forcing web developers to do their job well in following the Golden Rule :-) – Ilya Birman Mar 18 '09 at 23:42
  • @Milan your test application works in Chrome, except when you press the forward button it displays "Confirm Form Resubmission" (!) – Chris S Mar 19 '09 at 10:50
  • Possible duplicate of [How to prevent form resubmission when page is refreshed (F5 / CTRL+R)](https://stackoverflow.com/questions/6320113/how-to-prevent-form-resubmission-when-page-is-refreshed-f5-ctrlr) – Eugen Konkov Nov 12 '17 at 11:41

6 Answers6

38

See my golden rule of web programming here:

Stop data inserting into a database twice

It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”

If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.

Community
  • 1
  • 1
Ilya Birman
  • 9,834
  • 4
  • 27
  • 31
  • To produce the web page I need to supply about 4k of input. I cannot do that with GET. There is no "work" to be done, the output itself depends on the parameters given. The only think I can think of is to store that 4k of data in PHP session and retrieve it in the GET request, but if user has... – Milan Babuškov Mar 19 '09 at 10:13
  • 8
    It seems Amazon don't follow this golden rule – Chris S Mar 19 '09 at 10:44
  • 1
    Milan, just store your 4k in temp file and redirect to a page which will show data from it. Chris, huge number of websites are stupid, including the popular ones. That’s not a good excuse to make more stupid sites :-) – Ilya Birman Mar 19 '09 at 11:43
  • 6
    I'd say your "golden rule" is a bit simplified. If a POST doesn't succeed, there shouldn't be a redirect. Only after the request can be processed. The concept is also known as PRG or "redirect after post". – troelskn Mar 19 '09 at 12:13
  • If your script suddenly lost db connection and it can do nothing but display error message, including the data user has POSTed and a warning that it’s the last chance for user to copy his/her data, then yes, you’ll have to break the “golden rule”. – Ilya Birman Mar 19 '09 at 15:45
  • But this is not a normal scenario, which we are talking about here, it’s rather a recover plan for already failing application. – Ilya Birman Mar 19 '09 at 15:45
  • 1
    One problem with this method is that redirecting with a `303 See Other` response precludes sending an informative `2xx` response (eg. `201 Created`, `202 Accepted`). http://stackoverflow.com/questions/3383725/post-redirect-get-prg-vs-meaningful-2xx-response-codes – Ian Mackinnon Nov 02 '10 at 16:44
28

One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.

Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.


As a historical note, this technique was established practice in 1995.

sourcejedi
  • 3,051
  • 2
  • 24
  • 42
Pete Kirkham
  • 48,893
  • 5
  • 92
  • 171
  • 1
    But how? Input data is over 4kB and page output depends on it. – Milan Babuškov Mar 18 '09 at 22:43
  • Looks like I'll have to do it this way, unless there's some trick with the cache. – Milan Babuškov Mar 19 '09 at 10:17
  • 1
    don't use any tricks and do it exactly the way Pete suggested. what I like about his solution is that it follows simple REST principles. – lubos hasko Jan 15 '10 at 01:20
  • How does this prevent the user from going back? They go `back` from the 303 GET page they were redirected to - to the page they posted to. Post/Redirect/Get solves the problem of the user pressing `F5`, but it doesn't help when the user pressed the `back` button. (See Post/Redirect/Get on wikipedia http://en.wikipedia.org/wiki/Post/Redirect/Get) – Ian Boyd Nov 08 '10 at 18:28
  • 3
    @Ian suppose your browser GETs page A, which has a POST form on it. Your browser history has GET A in it. You post the form to B, and are redirected to GET C. You browser history now has GET A, GET C in it. It should not record POST B as browsers should not record the page in the history if it gets a 303 redirect. Try the sandbox at http://www.andypemberton.com/sandbox/prg/ and look at the browser's history to see if you get two or three pages. So the user doesn't go back to the result of the post, but back to the form. – Pete Kirkham Nov 08 '10 at 19:02
  • @Pete Kirkham Ahh, you're right. The user ends up on the "form" page, but not the "form-submitted" page. – Ian Boyd Nov 08 '10 at 20:21
4

One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.

Sparr
  • 7,489
  • 31
  • 48
  • 1
    Yes, that's my backup plan. But, BACK button does not work with AJAX, so I'll have to implement my own "back handler" in such case, which I want to avoid. – Milan Babuškov Mar 18 '09 at 22:45
2

I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:

//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
    $_SESSION['POST']=$_POST;
    redirect($_SERVER["REQUEST_URI"]);
}

//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
    $_POST=$_SESSION['POST'];
    unset($_SESSION['POST']);
}

Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.

rgbflawed
  • 1,957
  • 1
  • 22
  • 28
1

As another solution you may stop to use redirecting at all.

You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:

history.replaceState("", "", "/the/result/page")

See full or short answers

Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158
1

I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:

Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.

troelskn
  • 115,121
  • 27
  • 131
  • 155
  • 3
    There are no side effect, but parameters are 4kB. In case you did not know, GET has a limit of 1024 bytes. – Milan Babuškov Mar 19 '09 at 10:15
  • What kind of parameters is it that takes up that much space? Can you perhaps explain the context of your application a bit further? – troelskn Mar 19 '09 at 12:11
  • Pretend it's a reverse image search, where the post data is a picture. – Ian Boyd Nov 08 '10 at 18:12
  • @ian_boyd With that use-case, I would use POST to upload the image, then store the image someplace on the server side and respond with a redirect to a search page, which refers to a key, generated by the first request. If the application takes up too much space, you could prune the image store after some time. Browsers are smart enough to handle this gracefully - hitting back after leaving the redirected-to-page, will not prompt for repost. – troelskn Nov 08 '10 at 21:12