SecureForm: Protect Yourself from Form Post Failures Using AJAX
Case in point — you have an important web-based form and a visitor has spent 30 minutes filling it out. The visitor presses the “submit form” button and the form post fails (because the visitor has lost Internet connectivity or for any number of other reasons). The visitor gets some error screen, gets very annoyed, and quits. Form post lost, data lost, customer feedback, potential sale … lost.
How regular web forms work
Standard web forms have a <FORM … > tag that encloses all of the form fields in your form. This tag has a few properties that you specify. The most relevant to this discussion is the “ACTION” – the web address (URL) to send the data to.
Additionally, most web forms have some kind of button that is pressed to submit the form. When the visitor presses that button, the following happens:
- The browser scoops up all of the form fields and data in them and prepares it for transport.
- The browser gets the target address to which the data should be sent from the ACTION form parameter.
- The browser opens a connection to that ACTION address and sends all of the data using that connection.
- The browser displays the returned HTML content, replacing the currently displayed form page.
What can go wrong?
In most cases, the form submission and results display process works well. However, there are many things that can “go wrong”, causing the form post to fail and the visitor to get some kind of “error page” replacing the form input page s/he had been working on. Unexpected events include:
- The visitor’s Internet connection could have gone down or be working poorly.
- There could be a temporary problem with the Internet and the visitor can not connect to your form processing web server for the moment.
- The data center in which your web form processing server resides could be having networking, power, or other issues affecting the accessibility or uptime of your web form processing server.
- Your web form processing server or its firewall or other related hardware could fail.
- A software problem on your web form processing server may cause the processing of the form data to fail.
- Your web form processing server, or a server or service that it depends on, may be temporarily down for maintenance.
Some of these items can be mitigated to varying degrees by paying more money. E.g. you could have multiple web processing servers with redundant load balancers and redundant firewalls (LuxSci uses this model for its SecureForm service). However, while these do help:
- If the visitor is connecting to your server at the instant that a problem happens (a server, firewall, or other hardware failure), then no amount of hardware redundancy will save that connection. Sure, successive connections may properly fail over to other devices, but connections open and going through the device that failed will be broken.
- Increasing the number of devices and complexity of the configuration does increase the number of possible failure points.
- More expensive hardware and complex scenarios can further mitigate events.
Protecting Form Posts with AJAX
- Executes instead of directly submitting the form using the “submit button”
- Scoops up the form data and form fields and prepares them for transport
- Sends that data to the web form processing address
- Gets back the response from the web form processor
- Takes actions based on the response
- The submission succeeded and what data is returned, if any
- The submission failed for any reason … and some indication as to how it failed.
- Re-trying the sending to get around any very short “blip” in access to the server
- Telling the user that the post failed and asking them to re-try in a few minutes
- Saving the form in the browser’s memory so it can be auto-re-filled later and re-tried at that time
- Make the post to an alternate server in a geographically distinct location (as a fall back)