JQuery, XmlHttpRequest, the OPTIONS verb and Mr. Preflight

[Antaris Veteran]

Even confident developers get stuck sometimes!

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?

[azcodemonkey]

Have you tried specifying a callback, and not use XmlHttpResponse?

[Antaris Veteran]

It appears to be part of the design of the jQuery library. Checking through the source (v1.3.2), it only does a JSONP callback via the script tag with the Http type set to GET (which actually makes sense), switching to a GET instead of POST resolves the issue.

[azcodemonkey]

It appears to be part of the design of the jQuery library. Checking through the source (v1.3.2), it only does a JSONP callback via the script tag with the Http type set to GET (which actually makes sense), switching to a GET instead of POST resolves the issue.

Good to know. I'll jot that one down. :)

[pio!pio!]

Even confident developers get stuck sometimes!

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?

Thread bump!

Would you mind showing me how you modified jquery to not send the OPTIONS verb in Firefox? I have the same problem as you did. Either that, or getting IIS to understand the OPTIONS verb

[Antaris Veteran]

Hi,

The modification was actually not required. When you make a JSONP call, it actually achieves the cross-domain transparency by creating a new SCRIPT element on the page. Because you can't make a POST call from a SCRIPT element (it's only ever a GET), simply changing your POST to a GET will stop Firefox sending the OPTIONS header ahead for validation.

[pio!pio!]

Hi,

The modification was actually not required. When you make a JSONP call, it actually achieves the cross-domain transparency by creating a new SCRIPT element on the page. Because you can't make a POST call from a SCRIPT element (it's only ever a GET), simply changing your POST to a GET will stop Firefox sending the OPTIONS header ahead for validation.

So you're saying a cross domain POST is impossible using jQuery? My issue is that using a GET, I have to put the parameters in the querystring which I didn't want to do as that stuff will not be encrypted. (I was planning on POST'ing to an HTTPS site with authentication info). While developing I hosted the webservice on the same site and I was able to POST to it using $.post and sending the result to a callback. Now that it's been tested I moved the webservice over to HTTPS and herein lies the problem.

[Antaris Veteran]

So you're saying a cross domain POST is impossible using jQuery? My issue is that using a GET, I have to put the parameters in the querystring which I didn't want to do as that stuff will not be encrypted. (I was planning on POST'ing to an HTTPS site with authentication info). While developing I hosted the webservice on the same site and I was able to POST to it using $.post and sending the result to a callback. Now that it's been tested I moved the webservice over to HTTPS and herein lies the problem.

There is the problem though. You can't do a POST from a SCRIPT element. The browser will see the url that is set as it's source, and do a GET request on that, just like it would in any other resource (such as other SCRIPTS and LINKS [stylesheets]). The thing which will confuse many people, is that because they are actually doing the JSONP action via JQuery's ajax call, they assume its being done via XmlHttpRequest. It's not actually doing this, it's simply telling the browser there is another script to load. The way JSONP works, is that you pass a callback function name to whatever service you are dynamically calling, and that service has to wrap the JSON serialised data in that function call which allows it to evaluated at the client browser, e.g.:

GET http://somedomain.com/someservice/getMeSom...back=function01

Which should return it's serialised data something akin to:

function01({ data: { name = "Test", age = 25 }});

The browser succesfully returns that data because its a GET request across domains (which is allowed), and executes that function 'function01'.

Now, with the JSONP datatype, jquery automatically generates that callback function and name (this is overridable) and transparent handles this for you.

Unforetunately, you can't do this via POST. Hope that clears up the confusion somewhat.