PRG and AJAX
"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" 
- The Portland Pattern Repository lists it and links to examples and tutorials 
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)
- I am removing the notability tag. But in fact, reliable sources should be added, even if it costs effort. Adding tags accordinglý. Sorted as part of the Notability wikiproject. --B. Wolterding 19:28, 2 July 2007 (UTC)
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)
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. 220.127.116.11 (talk) 17:36, 13 August 2011 (UTC)
303 vs 302 responses
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 covering only a part
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. 18.104.22.168 (talk) 17:32, 4 November 2012 (UTC)
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 22.214.171.124 (talk) 14:00, 27 June 2014 (UTC)