• Skip to main content

Victor Font Consulting Group, LLC

The DEX Intranet Specialists

Call Us:

+1 919-604-5828

  • Home
  • Care Plans
    • Care Articles
    • Optional Subscriptions
  • Consultations
  • Products
    • Code Snippets
    • Public GitHub Repositories
    • Gist Snippets
    • Pastebin Snippets (Free)
    • Free Plugins
  • FAQs
  • Support
    • Graphic Design
  • Contact
    • Speakers
    • Portfolio
  • Resources
    • Free WordPress Video Training
    • Tutorials
    • Articles
    • Cybersecurity
    • EU Referral Network
You are here: Home / Ajax / jQuery.ajax() and Microsoft Browsers

jQuery.ajax() and Microsoft Browsers

By Victor M. Font Jr.
March 12, 20162 Comments

jQuery.ajax() and Microsoft Browsers, Freeimages.com/Svilen Milev
Contents
  • The Problem
  • The Analysis
    • Rule Out Cross-Site Scripting
    • HTTP GET vs. HTTP POST
    • Content Type
    • Encoding Special Characters
  • The Resolution

The Problem

You gotta love Microsoft! Sometimes I think they've taken liberties with their browsers that are designed just to be annoyances for the programming community at large. Case in point, we recently inherited a Formidable Pro project that uses a jQuery.ajax() call to retrieve a confirmation number from a database on a remote server when a user clicks on the form's submit button (See here). The remote server runs Windows and Internet Information Server (IIS). After refactoring the code to improve performance and overcome a timing issue, it all appeared to be working perfectly in all browsers, except that is…, (yes, you guessed it!), Internet Explorer. Now to only figure out why.

The Analysis

The jQuery.ajax() request as originally written looked like this:

The content is a well-formed XML record built with the values from the Formidable Pro form. Since we inherited this project, this code had already been built. We assumed that it was written to satisfy the specification provided by the customer. We did not have access to the original specifications to verify the work.

Rule Out Cross-Site Scripting

The path to the remote server is a subdomain of the primary domain. To help with the troubleshooting, we added a field to the Formidable Pro form and created a function to write to it as an error log. One of the errors recorded in a failed submission has a jqXHR status code of 0. Status code 0 is generally triggered when there is an attempt at cross site scripting and access is denied, or the connection is refused at the server. With this setup it could be one or both of these issues. We decided to rule out cross-site scripting first.

With cross-site scripting, subdomains are considered different than the primary domain and will fail the Same Origin Policy unless both domains declare the same document.domain DOM property (and even then, different browsers behave differently). The fact is that we are sending a request from a primary domain to a subdomain. To our eyes, this shouldn’t be a problem, but this is a problem for some browsers. Maybe it's a problem for IE? It certainly wasn't an issue for Firefox, Chrome, or Safari during our testing. The link to the Same Origin Policy provides some remedies for relaxing the cross site scripting issues. Adjusting the jQuery.ajax() request is as simple as adding "crossDomain: true" to the function's parameters. Again, this worked with every browser except IE. Cross-site scripting is eliminated as the cause for the IE failure.

HTTP GET vs. HTTP POST

When we tested with IE, as soon as the function was invoked we could see in the Network tab of the browser's development tools that the browser cancelled the request. It would not send the request to the server. Why would the browser cancel the request?

As it turns out, this was due to a long ago forgotten fact about Internet Explorer. IE is designed to restrict URLs to a length of 2083 characters. The records produced by the form easily exceed that length. If a URL is longer than the restricted length, IE will not process the request.

Ajax data can be sent over the Internet either through a HTTP GET or HTTP POST request. POST requests supply additional data from the client (browser) to the server in the message body. In contrast, GET requests include all required data in the URL. Ajax requests can use either method by specifying the type of the request as either "POST" or "GET" (default) in the Ajax function. The method specified determines how the data is submitted to the server. When the method is GET, all data is encoded into the URL, appended to the action URL as query string parameters. Remember query strings? Because of the GET, this request was being formed as //path-to-remote-server/?action=ajax-action&param1=param-value1&param2=param-value2&param3=param-value3, etc.. GET requests can create very long URLs. With POST, the data appears within the message body of the HTTP request, which effectively overcomes IE’s URL length limitation. Changing the Ajax request type to POST solved this problem.

Content Type

Changing the request type to POST introduced yet another problem. This time, viewing the Network request/response cycle in the browser's development tools, we could see that IE was sending the request, but the server was responding with a HTTP 500 internal server error.

POST request require a content type of "application/x-www-form-urlencoded; charset=UTF-8" (jQuery.ajax() default) regardless of the actual type of data being sent. The jQuery.ajax() request was sending data in XML format with its content type set to text/xml. IIS didn't like this. The solution was to remove contentType: "text/xml" from the request function so jQuery.ajax() used its default.

Encoding Special Characters

One last issue remained. IIS immediately rejected any Ajax request where one of the XML values included a special character. For example, if the value of a business name field was "Sanford & Sons, Inc.", the request choked because of the ampersand. Special characters need to be converted to HTML entities when sent through Ajax requests. Neither jQuery nor JavaScript have a direct function for converting special characters to HTML entities. The following quick 3-line function solves this issue.

This function works by creating a div in memory. The div does not exist on the page. The function assigns the passed parameter to the div's inner text, then returns the encoded content. To use this you simply pass the form's field value as the parameter.

Conversely, you can decode HTML entities into special character by reversing the text() and html() functions.

The Resolution

After all is said and done, here is the final code for the jQuery.ajax() call:

  • 1share
  • Facebook0
  • Twitter0
  • Pinterest0
  • LinkedIn1
  • Print
  • SMS0

About Victor M. Font Jr.

Victor M. Font Jr. is an award winning author, entrepreneur, and Senior IT Executive. A Founding Board Member of the North Carolina Executive Roundtable, he has served on the Board of Advisors, of the North Carolina Technology Association, the International Institute of Business Analysis, Association of Information Technology Professionals, Toastmasters International, and the North Carolina Commission for Mental Health, Developmental Disabilities, and Substance Abuse Services. He is author of several books including The Ultimate Guide to the SDLC and Winning With WordPress Basics, and Cybersecurity.

Reader Interactions

VictorFont.com runs on the Genesis Framework

Genesis FrameworkThe Genesis Framework empowers you to quickly and easily build incredible websites with WordPress. Genesis provides the secure and search-engine-optimized foundation that takes WordPress to places you never thought it could go.

Check out the incredible features and the selection of designs. It's that simple—start using Genesis now!

Click here to download The Genesis Guide for Absolute Beginners (PDF - 1.4 MB)

Leave a Reply Cancel reply

Your email address and website will not be published. Required fields are marked *
Posting a comment means that you agree with and accept our Comment & Product Review Policy

Comments

  1. Azmi

    April 16, 2016 at 8:22 pm

    Nice article Mr Victor, it’s very helpful
    I promise, I wanna share your article to my friends.
    Thank You.

    Reply
    • Victor M. Font Jr.

      April 17, 2016 at 6:42 pm

      Thank you Azmi.

      Reply

Call: +1 919-604-5828

Send us an E-mail

Accessibility Statement | Affiliate Marketing Disclosure | Capability Statement

Cookie Policy | Comment & Product Review Policy | Privacy Policy | Site Map | Terms & Conditions

Copyright © 2003–2023 Victor M. Font Jr.

Return to top of page