It looks like people are continuing to switch to Firefox. Which I love because there isn't many days that I don't curse IE. Mostly lately I've been cursing IE because it allows multiple form submissions while Firefox seems to guard against this on the client side. Nice.
What's the disadvantage of allowing multiple form submissions? Because it makes the server-side code more complicated? How are multiple form submissions handled by the HTTP protocol?
ReplyDeleteI don't think that it's defined in http.
ReplyDeleteHere's a run down example problem:
You e-comm site and you have a form that the user enters in their credit card info and what wingdings they want to buy. You have a "buy now!" button, after which the user is taken to a confirm screen.
Well in IE if the user presses "buy now!" and doesn't wait for the confirm screen and presses it again (double click) the browser makes 2 http submits to the server -> the person gets billed twice. Firefox seems to force you to wait for the page reload.
There's a pattern for this problem (of course) called "Synchronization Token pattern" (or something like that). What it means for html forms is putting a hidden token in the form and in the server session and only allowing form submissions where these match.
If you are using Struts it has this built right into the action class and makes it really easy. It will even put the token into the html form automatically.
http://www.javaworld.com/javaworld/javatips/jw-javatip136.html
Does this answer you questions?
I've done a nice write-up on some of the more developer-friendly features of firefox. head over to www.kibbee.ca to read more about them. :) </Shameless plug>
ReplyDeleteSo what you're saying is that IE doesn't support the token and Firefox does? It sounds like a good preventative measure.
ReplyDeleteI think what he's saying is that with firefox, you don't have to do anything special to get the form to not submit twice. With IE, you have to put this special token in so you can tell when somebody hits submity twice. I was not aware that firefox blocked double submitting.
ReplyDeleteCorrect Kibbee. ;-)
ReplyDeleteYou can also use the token so the user only follows a set path. eg. if they bookmark step 3 or 10, and then later go there, you can detect that they don't have the token and bump them back to step one.
Sounds almost like a cookie.
ReplyDeleteYes and no. It would be sort of like a cookie that you changed every time and kept a copy in the session. From what I know cookies are a way to push state onto the client. With a token you are keeping state on the server.
ReplyDeleteGood view though, I didn't think of it like that before.
When the web was designed to be stateless it must have been such a good idea. But since people have forced it into a stateful env. people have had to come up with so many different hacks to get around it. *sigh*
The problem with the web, and specifically web pages, is that, in the beginning they were never intended to be an application platform. http was designed to be stateless because it is the hyper text transfer protocol. There was no reason, at the time, for the transfer of hypertext to have any concept of state. All it was designed for was transferring static documents over the internet. This has caused many solution to come up about how to deal with handling states in a stateless environment. Most of the stuff out there like session cookies seems to work pretty well. However stateless(and therefore connectionless) adds a lot of advantages. A single server can suffice for thousands of users because they aren't connected when they don't need to be. Could you imagine the strain on a server if everybody had to stay connected?
ReplyDelete