LuxSci

SecureForm: Protect Yourself from Form Post Failures Using AJAX

Published: December 22nd, 2011

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.

This situation can be prevented and these important form posts saved by using some JavaScript (AJAX) techniques in your web form page.

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:

  1. The browser scoops up all of the form fields and data in them and prepares it for transport.
  2. The browser gets the target address to which the data should be sent from the ACTION form parameter.
  3. The browser opens a connection to that ACTION address and sends all of the data using that connection.
  4. 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.
You have to decide how much money you want to invest in your forms … 10s or 100s of dollars?  Or 10s or thousands of dollars per month?
For most, the benefit of reduced risk of failures by spending more is very small compared to the relative cost.  However, it turns out that you can prevent many of these problems by using AJAX (JavaScript) in your web forms.

Protecting Form Posts with AJAX

When a web form is submitted using AJAX, the process is a little different.  Your custom Javascript code:
  1. Executes  instead of  directly submitting the form using the “submit button”
  2. Scoops up the form data and form fields and prepares them for transport
  3. Sends that data to the web form processing address
  4. Gets back the response from the web form processor
  5. Takes actions based on the response
The big difference here is that your custom JavaScript code is in charge and not the web browser.  You find out directly if
  • The submission succeeded and what data is returned, if any
  • The submission failed for any reason … and some indication as to how it failed.
On success, your JavaScript can display a “Thank you message” or perform any other custom actions needed, like taking the user to a special page using the returned results of the form post.
On failure, you can also take custom actions, such as:
  • 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)
  • etc.
Therefore, you can handle most submission problems on the client side and provide business-appropriate and customer-friendly means to deal with that failure.   With a little web programming, you can mitigate most potential problems in your critical web forms.
LuxSci’s SecureForm web form processing service makes use of AJAX easy by providing the option for indicating post success/failure via simple HTTP status codes.

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.