Talk:Post/Redirect/Get

PRG and AJAX

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]

Notability

"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, 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)[reply]

Merge?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

The result was not to merge. I will remove the merger tag. --B. Wolterding 19:29, 2 July 2007 (UTC)[reply]

I find it hard to see what this has to do with REST. PRG has been around a lot longer than SOAP, REST and AJAX and is fundamental to making many web sites function correctly, and the lack of it is also the reason many sites still don't! I agree that this article could use some expansion, however. 24.57.191.81 17:13, 21 February 2007 (UTC)[reply]

REST was designed on the argument that there should be four HTTP operations: PUT, DELETE, POST, GET. Only the latter two are actually supported by most web browsers. The PRG pattern is an architectural "hack" that provides a work-around for the fact most web browsers still don't support PUT and DELETE. PUT and DELETE are idempotent operations. PRG is based around the fact that existing, widely-available POST and GET operations are stateless and there is no locking mechanism built into these resources. DO NOT MERGE. If anything, the request to merge is a sign that both the REST and PRG articles need housekeeping.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Move Page

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]

201 Created

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]

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. 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]

Article is Deficient

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]

Clarification of what clicking the refresh button does

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]