Horrible advice. But highly expedient if you're writing web apps in Java frameworks such as Struts. Some outtakes: "The convenience of caching affects standard behavior... Result page must not be returned in response to POST request, because attempt to reload it would cause double submit problem. Instead, browser must load result page separately, using GET method... Caching must be prohibited for web applications... The answer to double submit problem is redirection... It is interesting that PRG pattern exploits non-standard behavior of browsers and web servers." This article assumes the network is reliable, latency is zero and Java frameworks are architecturally significant :) Unfortunately, HTTP is an unreliable stateless protocol. Redirects and magic tokens can't help if the webapp crashes or the network goes to hell between a submit and a response, or someone uses a spec-conformant browser (don't even get me started on promoting a software pattern that relies on browser bugs :). An alternative answer to double submit is to provide the client with a one-shot URI that can only be submitted to at-most-once. The second time that request reaches the server it can tell the user the action has already been performed. Caching you don't have to worry about because you sent the one-shot URI for use in a POST method not some combination of GET/pragma/transaction-token. GET can be used for telling whoever is interested the status of the request (the URI can also act as a ticket). MVC is web poison....
Previous Topic
