Setting on an HTTP POST request as the last request sent to your server can get really dangerous. That is where Post Redirect Get (PRG) pattern comes into the picture.
What Is PRG?
PRG pattern is an approach to avoid setting on HTTP POST requests which may result in duplicate form submissions. When designing using PRG pattern, first we send POST request with data to the server, then, and instead of returning a web page directly, we return a REDIRECT from the POST request, that then leads the browser to send a GET request to get the page it’s being redirected to.
Why Should You Use PRG Pattern?
Let’s say you are developing a website for an online store. If you do not design, the purchasing form for example, using PRG pattern the users may eventually purchase something twice or more because of duplicate form submission. To be honest, the browser will warn the user when trying to resubmit the last POST request through refreshing. Beside being a very poor user experience, that is absolutely not a good idea to let the browser talk to the user, you want your application or website to be the one who talks to the user. Guess what! PRG pattern is made for this problem.
How to Implement PRG Pattern in PHP?
As mentioned earlier, we send a POST request, evaluate or process it, and return a REDIRECT, which leads to a GET request. Now, most of the cases, you would like to inform the user of what was the result of the process they were doing, maybe it failed, maybe there are other steps they need to do. And for that, you can either use Session variables or URL Parameters. Usually, I find using URL Parameters very useful. I set a couple of them on the URL of the page I am redirecting to, and then parse them with JavaScript and display them to the user.
Bad Code
Here is a regular piece of code, not following the PRG pattern and may not resemble a real life example.
We check for form submission via the POST variable on line 2
, evaluate/process the data, then output messages to the user via echo
. Refreshing this page after submitting the form would cause duplicate form submission. There might be also some problems with bookmarking this page.
Good Code
Now, let’s have a look at the same piece of code with PRG pattern applied.
We initialized session data on line 3
to put the message in SESSION variable later. Just like the other non PRG code, we check for form submission and evaluate data. But this time we put the message in SESSION variable. We then redirect to the next page with the header
function passing in the new location as shown on line 18
. On line 21
, we use exit
to terminate this script to make sure no more code gets executed. And to display the saved message to the user on the GET request, we check for the existence of the message in SESSION and output it to the user as on line 28
. Line 29
is only there to unset or clear the message variable to prevent showing it again on refresh.
Conclusion
Dealing with form submissions, specially those including financial processes, can get really tricky. PRG pattern is an easy to implement approach to overcome some problems that might happen because of duplicate form submissions. It also plays a pretty good role in improving user experience.
Note: You can find code samples for this article in this GitHub repo.