||This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. (January 2013)|
|This article needs additional citations for verification. (January 2013)|
Post/Redirect/Get (PRG) is a web development design pattern that prevents some duplicate form submissions, creating a more intuitive interface for user agents (users). PRG implements bookmarks and the refresh button in a predictable way that does not create duplicate form submissions.
Duplicate form submissions
When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.
To avoid this problem, many web developers use the PRG pattern — instead of returning a web page directly, the POST operation returns a redirection command. The HTTP 1.1 specification introduced the HTTP 303 ("See other") response code to ensure that in this situation, the web user's browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted. However most common commercial applications in use today (new and old alike) still continue to issue HTTP 302 ("Found") responses in these situations. Use of HTTP 301 ("Moved permanently") is usually avoided because HTTP-1.1-compliant browsers do not convert the method to GET after receiving HTTP 301, as is more commonly done for HTTP 302. However, HTTP 301 may be preferred in cases where it is not desirable for POST parameters to be converted to GET parameters and thus be recorded in logs.
The PRG pattern cannot address every scenario of duplicate form submission. Some known duplicate form submissions that PRG cannot solve are:
- If a web user refreshes before the initial submission has completed because of server lag, resulting in a duplicate HTTP POST request in certain user agents.
User agents (such as browsers) store only the URI of an HTTP request as a bookmark. Because of this, an HTTP POST request that results in a response based on the body of the HTTP POST request cannot be bookmarked. By using the PRG pattern, the URI of the HTTP GET request can safely be bookmarked by a web user. It is a question of the persistence of the data and the design of the URI whether bookmarking makes sense and is really working at every step of an application.
Since redirects are using absolute URIs, one has to take care about proxy servers (HTTP->HTTPS) and reverse proxy servers. If your application is such that a user uses an SSL tunnel to reach your site, this can cause problems also. (You may be able to use the Referer header to discover the domain and port the user is actually entering.)
- p36, "Universal Design for Web Applications", by Wendy Chisholm and Matt May, O'Reilly Media, Inc., 2008
- Ch. 8: Handling Form Submissions, "Realtime Web Apps: With HTML5 WebSocket, PHP, and jQuery", by Jason Lengstorf and Phil Leggetter, Apress., 2013