Bug Tracker

#4690 closed bug (wontfix)

Opened May 27, 2009 03:54PM UTC

Closed November 11, 2009 08:02PM UTC

Last modified March 15, 2012 03:28PM UTC

Chrome OPTIONS header type sent for POST ajax request, FF fails.

Reported by: m00b13s Owned by:
Priority: major Milestone: 1.4
Component: ajax Version: 1.3.2
Keywords: Cc:
Blocked by: Blocking:
Description

When using $.ajax as follows:

var url = "http://local.vhost/script";

var data = "foo=bar";

$.ajax({ type: "POST", url: url, data: data, cache: false, dataType: "jsonp", jsonp: "jsonp_callback", success: function(data) { }, error: function(data) { }, complete: function(data) { }});

I have been seeing an OPTIONS header rather than POST in my access logs.

127.0.0.1 - - [27/May/2009:16:45:48 +0100] "OPTIONS /integrator/api/1.1/booking HTTP/1.1" 401 -

Because this is a REST API I do not handle OPTIONS. I expect GET, POST or DELETE. The POST data is totally empty at the server.

Curiously PHP reports a correct HTTP_ACCESS_CONTROL_REQUEST_METHOD but Apache is seeing OPTIONS and PHP sees no $_POST data.

[HTTP_ACCESS_CONTROL_REQUEST_METHOD] => POST

[HTTP_X_REQUESTED_WITH] => XMLHttpRequest

[CONTENT_TYPE] => application/x-www-form-urlencoded

The above is when submitting with the new stable Chrome 2.0. In Firefox 3.1 beta 3, the request never reaches the server at all giving:

Access to restricted URI denied code: 1012

Despite that I have been using jsonp.

Attachments (0)
Change History (4)

Changed May 30, 2009 11:07PM UTC by malkarouri comment:1

I am seeing similar behaviour, also stable Chrome 2.0.172.28.

The code:

jQuery.get("http://localhost/myapp", {data: "hello"},

function(data){

alert("Data: " + data);

}

);

triggers an OPTIONS request rather than a GET one as seen by Apache. My setup is apache 2.2 on windows, mod_wsgi, python, django, so it's pretty different. One log line is:

127.0.0.1 - - [29/May/2009:16:58:25 +0100] "OPTIONS /myapp?data=hello HTTP/1.1" 200 2343

The code works successfully in IE6, executing a GET and receiving data.

Changed June 24, 2009 11:05PM UTC by simeyla comment:2

Able to duplicate this bug quite easily in Chrome BUT only if the ACTION for the form is on a different domain.

Error occurs if :

Page was served from :

http://ipv4.fiddler:62669/woops/TESTIMONIALS/X

Page was posted to :

http://dev.rollingrazor.com:62669/woops/TESTIMONIALS/X

These URLS point to EXACTLY the same ASP.NET web server (dev.rollingrazor.com is just an entry in my hosts file).

If the action is http://ipv4.fiddler:62669/woops/TESTIMONIALS/X or just X then I don't get the OPTIONS header sent

Chrome 2.0.172.31 on Windows

Changed August 04, 2009 11:42AM UTC by AntarisZX comment:3

I was looking through source 1.3.2, when using JSONP, the request is made by building a SCRIPT element dynamically, which gets past the browsers Same-domain policy. Naturally, you can't make a POST request using a SCRIPT element, the browser would fetch the result using GET.

As you are requesting a JSONP call, the SCRIPT element is not generated, because it only does this when the Type of AJAX call is set to GET.

Change your AJAX call to use GET instead of POST.

Changed November 11, 2009 08:02PM UTC by john comment:4

component: unfilled → ajax
resolution: → wontfix
status: new → closed

You are attempting to do a cross-domain POST. This does not work in most browsers. The only browsers that support it are those that support Cross-Site XMLHttpRequest. This is precisely what Chrome (and Firefox 3.5) is trying to do on your site:

https://developer.mozilla.org/En/Cross-Site_XMLHttpRequest

So yeah, not really something that we can handle on end, unfortunately.