Talk:Post/Redirect/Get

This article has not yet been rated on Wikipedia's content assessment scale.

Is it acceptable not to follow this pattern when processing AJAX requests? —Preceding unsigned comment added by 192.156.102.7 (talk) 11:58, 22 April 2011 (UTC)[reply]

This pattern was introduced for a reason. If the reason is gone, you don't need to follow the pattern. Can users bookmark AJAX requests? Are users able to re-submit an AJAX POST request be reloading the page? -- Rillke (talk) 23:57, 8 December 2015 (UTC)[reply]

"redirect after post", in quotes, yields over 11,000 results in Google, among them several notable ones, such as:

• Apache Struts calls it "a common pattern in web application development" [1]
• The Portland Pattern Repository lists it and links to examples and tutorials [2]

I can probably waste a whole lot of valuable time digging up notable sites and people reinforcing this pattern, but hopefully that won't be needed. Ubernostrum 17:42, 29 January 2007 (UTC)[reply]

• I am removing the notability tag. But in fact,
  Notability wikiproject. --B. Wolterding 19:28, 2 July 2007 (UTC)[reply
  ]

Outside of Wikipedia articles on Google, it seems most sites format it as POST-Redirect-GET and Post-Redirect-Get. I'd like to see the article get moved to one of these because the talk page is picking up the slashes as subpages. Another suggestion: PRG (computer science) -- unless, of course, someone knows how to fix the slash problem. --Quilokos (talk) 12:21, 11 July 2009 (UTC)[reply]

What is the best practice with regard to creating resources? Send a 201 with Location set to the new resource, or a 303? The article HTTP location seems to also have things to say about this. 70.30.85.6 (talk) 17:36, 13 August 2011 (UTC)[reply]

The article currently says: "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."

This is not true. RFC 2616 is so clear on this point that I only really need to quote it:

10.3.4 303 See Other

  The response to the request can be found under a different URI and
  SHOULD be retrieved using a GET method on that resource. This method
  exists primarily to allow the output of a POST-activated script to
  redirect the user agent to a selected resource. The new URI is not a
  substitute reference for the originally requested resource. The 303
  response MUST NOT be cached, but the response to the second
  (redirected) request might be cacheable.
  
  The different URI SHOULD be given by the Location field in the
  response. Unless the request method was HEAD, the entity of the
  response SHOULD contain a short hypertext note with a hyperlink to
  the new URI(s).
  
     Note: Many pre-HTTP/1.1 user agents do not understand the 303
     status. When interoperability with such clients is a concern, the
     302 status code may be used instead, since most user agents react
     to a 302 response as described here for 303.

So yes, 303 was introduced for exactly this purpose, but notice "the 302 status code may be used instead."

The pattern is fine when data should be transfered from a form to the server by post. However, the same pattern should be applied when a link (with some get parameters) changes the model state at the server. Conside a delete button on a page. This could be an empty form with a button or a link. In both cases the call should not be 'reloaded' again. So in my opinion the pattern is somehow 'insufficient'. Could be noted in the article. 86.56.182.226 (talk) 17:32, 4 November 2012 (UTC)[reply]

A GET request should not change the model state at the server. HTTP states that the GET method is both idempotent and safe. — Preceding unsigned comment added by 181.46.202.70 (talk) 14:00, 27 June 2014 (UTC)[reply]

Additionally, these requests should have a CSRF-token attached. Never make delete links, nor delete forms using method=GET. Currently working on a page which suffers from this kind of crap. -- Rillke (talk) 00:01, 9 December 2015 (UTC)[reply]

This article is very deficient. It never explains clearly what the problem is, it doesn't describe the solution, and it gives no examples. —MiguelMunoz (talk) 20:16, 13 February 2013 (UTC)[reply]

problem is "duplicate form submissions", solution is given in the title, and Wikipedia is not the place for programming examples. — Preceding unsigned comment added by 24.89.139.58 (talk) 14:09, 8 April 2013 (UTC)[reply]

It took me a while to understand this because I kept assuming that clicking refresh just sends a GET request to whatever is in the URL bar. The way it really works is it performs the last HTTP request. The last HTTP request isn't necessarily a GET to whatever's in the URL bar. I think this should be clarified. Adamzerner (talk) 02:24, 3 February 2015 (UTC)Adam Zerner[reply]

Newer browsers at least ask the user whether they want to re-issue a POST request and warn them about shopping twice. -- Rillke (talk) 00:03, 9 December 2015 (UTC)[reply]