Post-Redirect-Get ?'s

Hurshai

Limp Gawd
Joined
Jul 10, 2006
Messages
436
I'm trying to work out a problem we're having with form submittal and the POST method. We have a web application that works as a bug report mechanism for our web portal. A user submits the report and an e-mail is sent to us so we can examine their issue. Once the form is submitted, they are forwarded to a confirmation page. If the user reloads the page from the confirmation page, the report will be submitted again and we receive duplicate reports.

The Post-Redirect-Get pattern is the only solution I have been able to dig up to this point. I'm having a hard time wrapping my head around this and figuring out how to implement it into the code (we're using JSP with an OC4J server). I'm wondering if I should continue to pursue this route or if any [H] web gurus have a better solution.

Let me know if I can clarify anthing.
 
This is the right way to do it, though I never knew it had a name. I'm not familiar with JSPs at all but it should be easy to google or otherwise find out. All you need to do is send the header 'Redirect: http://path.to/redirect/to'. In PHP you use the header() function, in Rails you use redirect_to in a controller. The redirect is a simple GET, so that's all there is to it. I even found a thread that seems relevant.
 
Its header("location: http://url"), not redirect. By the way-- header() only works if no body is sent, so be sure to not dump any white space out before hand.
 
Huh. That's a fancy method. What I've done in the past has been a bit heavy, but it protects against this and malicious form submittals too.

Every form the code generates has a unique key, with a corresponding entry in the database. As that form is submitted, the key is removed from the database. Every key can only be submitted once, obviously, so problem solved.

Probably not the best way to do it though.
 
Thanks Samson, I spent some time googling it every which way but never ran across that link. I'll give it a shot. Thanks to everyone else as well!!
 
^ Storing a unique key in the database to track form submissions sounds awfully database intensive, and if anything way more extreme. The redirect back to the completion page is common practice and pretty easy compared to inserting and removing rows in a db (plus you don't strain your server).
 
html form page -> jsp handler page -> confirmation page.

user never actually sees the jsp handler page, you use the jsp to do your stuff and then you use a response.sendRedirect() to bounce them to the confirmation page.
 
^ Storing a unique key in the database to track form submissions sounds awfully database intensive, and if anything way more extreme. The redirect back to the completion page is common practice and pretty easy compared to inserting and removing rows in a db (plus you don't strain your server).
Hey, never said it was the best way! :)
 
^ Storing a unique key in the database to track form submissions sounds awfully database intensive, and if anything way more extreme. The redirect back to the completion page is common practice and pretty easy compared to inserting and removing rows in a db (plus you don't strain your server).

Single row insert/update/deletes are 'awfully database intensive'? What kind of squirrel-powered DB are you using?

While not the absolute pinnacle of software design, I can point out at least on system that does this for every form : Drupal (maybe it uses something in the session - the difference is negligible). Not only does it prevent dual-form submissions, but it also slows spammers down a bit by forcing them to use a spam-bot smart enough to reload & reparse the form between each submission.
 
^ When you deal with high profile websites, wasting DB requests on tracking forms is database intensive. I can promise you its a bad design, and the reality is its a fake sense of security. Anyone who deals with replication will tell you-- writes are valuable, and your main bottlekneck. Wasting them on something like this is retarded.
 
Back
Top