jquery.ajax post request missing content-type in IE9, works in Chrome

Question

I'm trying to perform the following jQuery.ajax request and I'm facing a weird problem.

When I'm sending this request using IE9 the contentType parameter is missing although I sent it, on chrome the request is ok.

$.ajax({
        type: "POST",
        contentType: "application/x-www-form-urlencoded",        
        url: this.AgentServiceUrl + "/" + methodName,
        data: data,
        async: true,
        success: function (xml, textStatus) { if (successHandler != null) successHandler(xml, textStatus); },
        error: function (xmlHttpRequest, textStatus, errorThrown) { if (errorHandler != null) errorHandler(state, xmlHttpRequest, textStatus, errorThrown); }
    });

I'm using jQuery 2.0.2 and jQuery.XDomainRequest.js to work with cross domain requests.

What can I do??

Answer 1

$.ajax uses XDomainRequest in order to allow AJAX applications to make safe cross-origin requests

In Internet Explorer 8, the XDomainRequest object was introduced. This object allows AJAX applications to make safe cross-origin requests directly by ensuring that HTTP Responses can only be read by the current page if the data source indicates that the response is public

but unfortunately only text/plain is supported for the request's Content-Type header

In the original incarnation of the XDomainRequest object, we allowed specification of the Content-Type for a POST request. It was pointed out that this violated our goal of emitting only requests that HTML Forms can issue, because HTML Forms are limited to sending data in three different content types: text/plain, application/x-www-urlencoded, and multipart/form-data. In particular, it was pointed out that some AJAX server libraries would blindly assume that if they received a request with a SOAP or JSON Content-Type, then the client must either be trusted or Same Origin (because HTML itself previously offered no way to issue cross-origin requests with that Content-Type).

Unfortunately, when we fixed this problem in a later IE8 Beta, we went a bit too far; we restricted the content type to text/plain but didn’t allow the caller to specify that the data was in application/x-www-urlencoded form. This is problematic because server-side frameworks (e.g. ASP, ASPNET, etc) will only automatically parse a request’s fields into name-value pairs if the x-www-urlencoded content type is specified.

To workaround this issue, server code that currently processes HTML Forms must be rewritten to manually parse the request body into name-value pairs when receiving requests from XDomainRequest objects. This makes adding support for the XDomainRequest object more difficult than it would be otherwise.

Source