HTTP OPTIONS Pre-flight request Load Cancelled with pending Status in Chrome

Question

I am using Sencha Touch 2.1.0. I am making a HTTP GET call. It is a CORS request. Hence it is sending Pre-flight HTTP OPTIONS command as expected.

I have installed CORS filter on my server and configured it. The calls from my code were going through very well till yesterday. Suddenly today it stopped loading data. When I check the Network calls in Chrome, I see that the OPTIONS method shows up as "Load cancelled"

Method: OPTIONS
Status Text: "Load cancelled"
Type: pending
Initiator: Connection.js:319

I had a similar issue when I configured CORS filter for the first time. When I cleared browser cache, it started working. This time, I am not sure why it suddenly stopped working. It is not getting fixed even when I clear the cache and history in the browser.

If I make the same exact call from HTTPRequestor in Firefox it works very well. Here is the call. I have masked url due to confidentiality reasons.

OPTIONS http://myurl/rest/items?_dc=1358304888220&page=1&start=0&limit=25 HTTP/1.1
Access-Control-Request-Method: GET
Origin: http://localhost:8080
Access-Control-Request-Headers: accept, origin, x-requested-with

The same exact request gives me a very good response from HTTPRequestor. Here is the result:

OPTIONS http://myurl/rest/items?_dc=1358304888220&page=1&start=0&limit=25
Access-Control-Request-Headers: accept, origin, x-requested-with
Access-Control-Request-Method: GET
Origin: http://localhost:8080


 -- response --
200 OK
Date:  Wed, 16 Jan 2013 03:19:27 GMT

Server:  Apache-Coyote/1.1

Access-Control-Allow-Origin:  http://localhost:8080

Access-Control-Allow-Credentials:  true

Access-Control-Allow-Methods:  HEAD, GET, POST, OPTIONS

Access-Control-Allow-Headers:  X-Requested-With, Origin, Accept, Content-Type

Content-Length:  0

Strict-Transport-Security:  max-age=15768000, includeSubDomains

Keep-Alive:  timeout=15, max=100

Connection:  Keep-Alive

Sencha code in the Store to make this call:

    proxy: {
        type: 'ajax',
        method: 'GET',
        url: 'http://myurl/rest/items',
        withCredentials: true,
        useDefaultXhrHeader: false,
        disableCaching: false,
        headers: {
            "Accept": "application/json"
        },
        failure: function(response) {
            if (response.timedout) {
                Ext.Msg.alert('Timeout', "The server timed out :(");
            } else if (response.aborted) {
                Ext.Msg.alert('Aborted', "Looks like you aborted the request");
            } else {
                Ext.Msg.alert('Bad', "Something went wrong with your request");
            }
        },
        success: function(response){
            Ext.Msg.alert(response.responseText);
        }
    },
    autoLoad: true,

Please help me understand how I can fix this issue.

Fireball

Can you show the JavaScript code you are using to make the request? Are you setting .withCredentials = true;? – Lees

@Monsur, I just added the sencha code that is used to make this call. Yes withCredentials is true. This code was actually working till the day before yesterday and it stopped working suddenly. I am not sure what went wrong. I did not make any changes on the server side. – Fireball

Answer 1

This seems to be an issue due to the last Google Chrome update. When I try with Iron browser, it works.

Fireball

Answer 2

I have just solved this problem. Server response Header should be set as:

"Access-Control-Allow-Origin": "*"
"Access-Control-Allow-Headers": "Origin, X-Requested-With, Content-Type, Accept"

You have done this already. I think if GET or POST method contains X-Requested-With header, OPTIONS method will be sent first. X-Requested-With header is in the default XHR header. So we should set 'useDefaultXhrHeader' to false. Ext.data.Store didn't support this parameter. Edit sdk/src/data/Connection.js, change default value of useDefaultXhrHeader to false.

Honor

Answer 3

I was having a similar issue in beta versions of Webkit browsers. As it turns out, the Content-Type header is being set implicitly for XMLHttpRequests containing Blobs, so I had to add that to the Access-Control-Allow-Headers on my upload server.

See: https://bugs.webkit.org/show_bug.cgi?id=99983

Gawlas