JQuery, XmlHttpRequest and Status Code 0

Question

I've recently been doing some Cross-domain javascript using JSONP, and ASP.NET MVC.

The particular Controller action will only respond to a POST request, this is by design.

In IE8, I can see (via Fiddler2) that the response is correct, and returning a HTTP 200 response, along with the JSONP javascript.

In Firefox, Safari and Chrome, the response is still being returned, with the appropriate HTTP 200 code and JSONP content, the only difference is that the XmlHttpRequest object being used by JQuery is setting the status code to 0, and the responseText to empty.

Originally, I thought this was due to COR HTTP Preflighting (Http Access Control), whereby a custom header or a content-type other than text/plain would cause an additional HTTP request (with an OPTIONS) verb to be sent to the server. I can see in Fiddler2 that the OPTIONS request is being responded to with a HTTP 404.

The web server is IIS7 (but the production web server will be an IIS6 box). In IIS7, I can see the standard OPTIONSVerbHandler listed in the handlers, but I'm not convinced this is actually doing anything (in fact, I can't even find any documentation about the OPTIONSVerbHandler anywhere).

To get round this, I modifed the JQuery library to not set the custom header, and change the content-type to text/plain instead of application/json, and Firefox finally starts bypassing the OPTIONS request, and just plain POSTs.

The problem still lies in an empty response (according to the XmlHttpRequest object), even though Fiddler2 shows that a successful HTTP 200 response, with content is being returned.

Any help?

Solution 1

Turns out, you can't use Cross-Domain calls with JQuery using POST (which makes sense, as it renders a script tag to make the call). Switching to GET sorted the issue, and now everything is returning correctly.

Had to walk through the JQuery source to figure that one out, but thanks for the reply.

Matt

Solution 2

Try using firebug in firefox to see the actual request being sent. Check out the net tab to see the HTTP request and response. Maybe something is misconfigured? I also use jsonview in firefox to view JSON data that sets the applcaiton/json mimietype. Sadly it doesn't handle JSONP, but its close.

Solution 3

Actually NOT THE CASE. Firefox sends an OPTION header like the following:

Here is what is getting set by the client in Firefox:

OPTIONS /MvcApplication/Json/Test1 HTTP/1.1
Host: acoheni580
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Origin: http://localhost
Access-Control-Request-Method: POST

Mvc doesn’t know how to handle this because it is only looking for a POST header when using the attribute [HttpPost]

To manually allow this:

//[HttpPost]
[AcceptVerbs(new string[] {"POST","OPTIONS"})]

Solution 4

Other than all the obvious errors on the client side, the main reason for this is that gecko engine looks for the Access-Control-Allow-Origin in the header from the servlet. If it does not find it, it will abort the communication and you get a status=0 and statusText=null. Also, the moz-nullprincipal in xml parsing error. All of this stuff is very misleading. All you need to resolve this problem is:

response.setHeader("Access-Control-Allow-Origin","*");

In the servlet code and life will be good :-)

View more solutions