Software Development Resources
Create account | Log in | Log in with OpenID | Help

POST-Redirect-GET

From DocForge

POST-Redirect-GET, or GET-After-POST, is a design pattern used by some web applications in which the web browser is redirected to a page immediately after the web server finishes processing an HTTP POST request. This can improve usability after a user submits a form by letting the user refresh the page or browse back to the page without resubmitting the form.

[edit] Objective

Traditionally, a web application will receive one request and respond directly with page content. In the case of a form submission by the user, this entails processing the POST and generating content all in one response. Subsequently, when the user attempts to browse to the page again, the web browser will attempt to request it the same way (often confirming with the user), by sending another HTTP POST. This can result in undesirable duplicate data, which can be detrimental to both the user and to web application data.

By redirecting the user to a new page immediately after processing the form submission, the browser is executing an HTTP GET. When the user attempts to return to the page the web browser executes another GET, skipping reposting the form. Therefore the user can refresh the page or browse back to it with no negative consequences.

[edit] Implementation

Upon receiving an HTTP POST request, the web application processes the form post. Before responding with any content, the web application sets the response header:

  • HTTP/1.1 302 Found or HTTP/1.1 303 See Other
  • Location: http://www.example.com/page

The web application then stops execution, sending back no content with the response. Upon seeing the header, the web browser will immediately make a new GET request for http://www.example.com/page. This page might contain a "Thank you for your submission" message, a purchase receipt, or some other information useful to the end user.

[edit] Use Cases

POST-Redirect-GET can be useful in many form posting scenarios, in particular:

  • User login
  • Payment processing, where it's especially critical that duplicate transactions aren't accidentally processed

This design pattern should not be used in place of a form GET in cases where that is more appropriate. For example, a search form posting GET instead of POST would let the user bookmark the search results.

Discuss