Talk:Post/Redirect/Get

message: 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)
replies: text: 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)
thread_title: PRG and AJAX

message: "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)
thread_title: Notability

message: The result was not to merge. I will remove the merger tag. --B. Wolterding 19:29, 2 July 2007 (UTC)
thread_title: Merge?

message: 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)
thread_title:  Move Page 

message: 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)
thread_title:  201 Created 

message: 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)
replies: text: 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)

text: 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)
thread_title:  The pattern is covering only a part 

message: 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)
replies: text: 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)
thread_title:  Article is Deficient 

message: 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)
replies: text: 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)
thread_title:  Clarification of what clicking the refresh button does