Background: We are in the process of writing a registration/payment page, and our philosophy was to code all validation and error checking on the server side first, and then add client side validation as a second step (un-obstructive jQuery).
We wanted to disable double clicks server side, so we wrote some locking, thread-safe code to handle simultaneous posts/race conditions. When we tried to test this, we realized that we could not cause a simultaneous post or race condition to occur.
I thought that (in older browsers anyway) double clicking a submit button worked as follows:
User double clicks submit button.
Browser sends a post on the first click
On the second click, browser cancels/ignores initial post, and initiates a second post (before the first post has returned with a response).
Browser waits for second post to return, ignoring initial post response.
I thought that from the server side it looked like this: Server gets two simultaneous post requests, executes and responds to them both (unaware that no one is listening to the first response).
From our testing (FireFox 3.0, IE 8.0) this is what actually happens:
User double clicks submit button
Browser sends a post for the first click
Browser queues up second click, but waits for the response from the first click.
Response returns from first click (response is ignored?).
Browser sends a post for the second click.
So from a server side: Server receives a single post which it executes and responds to. Then, server receives a second request wich it executes and responds to.
My question is, has this always worked this way (and I'm losing my mind)? Or is this a new feature in modern browsers that prevents simultaneous posts to be sent to the server?
It seems that for server side double click prevention, we don't have to worry about simultaneous posts or race conditions. Only need to worry about queued up posts.
Thanks in advance for any feedback / comments.
Alex
