internet-explorer - jquery.ajax post 请求在 IE9 中缺少内容类型，在 Chrome 中有效

Question

我正在尝试执行以下 jQuery.ajax 请求，但遇到了一个奇怪的问题。

当我使用 IE9 发送此请求时，尽管我发送了 contentType 参数，但在 chrome 上该请求正常。

$.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); }
    });

我使用 jQuery 2.0.2 和 jQuery.XDomainRequest.js 来处理跨域请求。

我能做什么？

Answer 1

$.ajax 使用 XDomainRequest 来允许 AJAX 应用程序发出安全的跨域请求

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

但不幸的是，请求的 Content-Type header 仅支持 text/plain

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