Jump to content

Post/Redirect/Get: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m Reverted edits by 220.225.231.116 (talk) to last revision by Dinamik-bot (HG)
Clarified application behavior. May require ref but that can be shown via a simple investigation of most popular web properties
Line 7: Line 7:
When a web form is submitted to a server through an [[Hypertext Transfer Protocol|HTTP]] [[POST (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 [[Purchasing|purchase]].
When a web form is submitted to a server through an [[Hypertext Transfer Protocol|HTTP]] [[POST (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 [[Purchasing|purchase]].


To avoid this problem, many web developers use the PRG pattern &mdash; instead of returning a web page directly, the POST operation returns a redirection command (using the [[HTTP 303]] response code (sometimes [[HTTP 302]]) together with the HTTP "Location" response header), instructing the browser to load a different page using an HTTP GET request. A web user can then safely refresh the server response without causing the initial HTTP POST request to be resubmitted. Use of [[HTTP 301]] is usually avoided because some browsers do not convert the method to GET after receiving HTTP 301, as is more commonly done for HTTP 302.<ref>{{cite web|url=http://tools.ietf.org/html/rfc2616#section-10.3.3|title=HTTP/1.1}}</ref>
To avoid this problem, many web developers use the PRG pattern &mdash; instead of returning a web page directly, the POST operation returns a redirection command. Proper compliance for HTTP 1.1 spec requires that applications provide a [[HTTP 303]] response in this situation to ensure that the web user's browser can then 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]] responses in these situations. Use of [[HTTP 301]] is usually avoided because some browsers do not convert the method to GET after receiving HTTP 301, as is more commonly done for HTTP 302.<ref>{{cite web|url=http://tools.ietf.org/html/rfc2616#section-10.3.3|title=HTTP/1.1}}</ref>


The PRG pattern cannot address every scenario of duplicate form submission. Some known duplicate form submissions that PRG cannot solve are:
The PRG pattern cannot address every scenario of duplicate form submission. Some known duplicate form submissions that PRG cannot solve are:

Revision as of 00:25, 11 June 2010

Diagram of a double POST problem encountered in user agents.
Diagram of the double POST problem above being solved by PRG.

Post/Redirect/Get (PRG) is a common design pattern for web developers to help avoid certain duplicate form submissions and allow user agents to behave more intuitively with bookmarks and the refresh button.

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. Proper compliance for HTTP 1.1 spec requires that applications provide a HTTP 303 response in this situation to ensure that the web user's browser can then 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 responses in these situations. Use of HTTP 301 is usually avoided because some browsers do not convert the method to GET after receiving HTTP 301, as is more commonly done for HTTP 302.[1]

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 goes back to the web form and resubmits it.
  • if a web user clicks a submission button multiple times before the server response loads (may be prevented by using JavaScript to disable the button after the first click).
  • 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.

Bookmarks

User agents 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's 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.

Proxy Server

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 a SSL tunnel to reach your site, this can cause problems also. (You may be able to use the Referrer header to discover the domain and port the user is actually entering.)

References

  1. ^ "HTTP/1.1".
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Post/Redirect/Get&oldid=367323045"