views:

3069

answers:

3

Hi All,

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?

A: 

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.

Paul Tarjan
+2  A: 

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

Matthew Abbott
A: 
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"})]

Andrew Cohen