The Post Redirect Get Pattern
Sometimes I look at old draft blog entries and ask myself “what was I thinking?”. Every once in a while, though, I look at an old draft post and say “hey, that’s pretty cool!”. This article fell into the pretty cool category, not so much for the content, but the example app, so I hope you enjoy it (OK, you can skip to the end now).
There’s a long-standing, accepted pattern for handling form submissions in web applications; it’s usually called the post redirect get pattern. The goal of the pattern is to prevent the payload of a HTTP POST request from being stored in the browser history.
Keeping the POST data out of the browser history helps prevent duplicate form submissions and also is the best way to make sense out of navigating backward/forward through the history after a post. Imagine refreshing a webpage without the PRG pattern after making a credit card purchase.
To speak in HTTP terms, the PRG pattern intends to handle the non-idempotent nature of the POST method. As defined by the HTTP specification, it’s not safe to submit the same POST data more than once, so the PRG pattern prevents the user from resubmitting POST data when refreshing their browser window or navigating through their browser history.
As I mentioned, this is a long-standing pattern and as such, there are several references available that describe it in full detail:
It is also widely implemented in most modern web application frameworks (eg: JBoss Seam, Ruby on Rails) and because it avoids problems caused by HTTP itself, it is implemented in various web-specific languages/frameworks (JavaEE, .NET, PHP, Python, Ruby, etc).
OK, so why did I think this post was worth finishing? Well, many moons ago, I built out an example application in PHP demonstrating the post redirect get pattern.
Hope you find it useful.