[javascript] jQuery Ajax requests are getting cancelled without being sent

I am trying to hook up a script to Microsoft's World-Wide Telescope app. The latter listens on port 5050 for commands. It is running on the same machine as the browser (Chrome right now, but as far as I can tell the behavior is the same with Firefox 7 and IE 9).

I am sending a "Access-Control-Allow-Origin: *" header with the original html file to try to eliminate XSS restrictions as my problem.

My code to access WWT is as follows:

$.ajax({
    type: 'POST',
    url: url,
    data: data,
    crossDomain: true,
    success: success,
    dataType: dataType
});

url in this case is "http://127.0.0.1:5050/layerApi.aspx?cmd=new&..." (obviously ... is shorthand here for some additional parameters).

Looking at the network diagnostics in Chrome, I can see this:

Request URL:http://127.0.0.1:5050/layerApi.aspx?cmd=new&...
Request Headersview source
Accept:application/xml, text/xml, */*; q=0.01
Content-Type:application/x-www-form-urlencoded
Origin:http://gwheeler4
Referer:http://gwheeler4/conceptconnect.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

The request is going out - I see WWT make a new layer. However, I don't get a callback. If I add an error callback that gets called, but the error property on the jqXHR object is just "error" and status is 0. If I look at the network request in Chrome I see "(cancelled)" as the status and no response.

If I take that same URL and paste it in a new browser tab, I can see that the response is the expected XML.

Of course, a difference here is that this is a GET not a POST, but I've tried that in my script and it makes no difference.

I'm pretty stumped by this and would appreciate any fresh ideas.

For Dropzone.js case. In my case it's was caused because of timeout option value was too low by default. So increase it by your needs.

{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}

I have had the same problem, for me I was creating the iframe for temporary manner and I was removing the iframe before the ajax become completes, so the browser would cancel my ajax request.

In my case, I Apache's mod-rewrite was matching the url and redirecting the request to https.

Look at the request in chrome://net-internals/#events.

It will show an internal log of the request. Check for redirects.

I had the same problem, but in my case it turned out to be a cookie issue. The guys working on the back-end had changed the path of the JSESSIONID cookie that's set when we log in to our app, and I had an old cookie by that name on my computer, but with the old path. So when I tried logging in the browser (Chrome) sent two cookies called JSESSIONID, with different values, to the server - which understandably confused it - so it cancelled the request. Deleting the cookies from my computer fixed it.

Two possibilities are there when AJAX request gets dropped (if not Cross-Origin request):

1. You are not preventing the element's default behavior for the event.
2. You set timeout of AJAX too low, or network/application backend server is slow.

Solution for 1): Add return false; or e.preventDefault(); in the event handler.

Solution for 2): Add timeout option while forming the AJAX request. Example below.

$.ajax({
    type: 'POST',
    url: url,
    timeout: 86400,
    data: data,
    success: success,
    dataType: dataType
});

For Cross-origin requests, check Cross-Origin Resource Sharing (CORS) HTTP headers.

I had the cancelled in Firefox. Some ajax-calls working perfectly fine for me, but it failed for the coworker who actually had to use it.

When I checked this out via the Chrome tricks mentioned above, I found nothing suspicious. When checking it in firebug, it showed the 'loading' animation after the two mallicous calls, and no result tab.

The solution was mega simple: go to history, find the website, rightclick -> forget website.
Forget, not delete.

After that, no problems anymore. My guess is it has something to do with the .htaccess.

I got this error when making a request using http to a url that required https. I guess the ajax call is not handling the redirection. This is the case even with the crossDomain ajax option set to true (on JQuery 1.5.2).

I had this error in a more spooky way: The network tab and the chrome://net-internals/#events did not show the request after the js was completed. When pausing the js in the error callcack the network tab did show the request as (cancelled). The was consistently called for exactly one (always the same) of several similar requests in a webpage. After restarting Chrome the error did not rise again!

I had a similar issue. Using chrome://net-internals/#events I was able to see that my issue was due to some silent redirect. My get request was being fired in an onload script. The url was of the form, "http://example.com/inner-path" and the 301 was permanently redirecting to "/inner-path". To fix the issue I just changed the url to "/inner-path" and that fixed the issue. I still don't know why a script that worked a week ago was suddenly giving me issue... Hope this helps someone

(Using Web Forms ASP.NET)

My issue was I was trying to fire Ajax off the click event of a submit button that had a server side click event setup. I had to make the button just a simple button (i.e. <input type="button"> )

Expanding on @Kazetsukai's answer, you may run into this problem if you are making your AJAX request from the user clicking on a link.

If you set up your link like so:

<a href="#" onclick="soAjax()">click me!</a>

And then a javascript handler like the following:

soAjax() {
    $.ajax({ ... all your lovely parameters ... });       
}

To prevent your browser from following the link and cancelling any requests in progress, you should add return false or e.preventDefault() to stop the click event from propagating:

soAjax() {
   $.ajax({ ... etc ... });
   return false;
}

Or:

soAjax(e) {
   $.ajax({ ... etc ... });
   e.preventDefault();
}

In my case I was having type='submit' so when I was submitting the form the page was reloading before the ajax hit going so a simple solution was to have type="button". If you don't specify a type it's submit by default so you've gotta specify type="button"

type='submit' => type='button'

OR

No type => type='button'

Or if you don't want to change the type or submit the form on click you can e.preventDefault() as the very first thing e.

<button>Submit</button>
 
<script>
$( "button" ).click(function( event ) {
  event.preventDefault();
  // AJAX Call here
});
</script>

In my case, it was the missing trailing slash in the url. Adding the trailing slash solved my problem.

I had a similar problem. In my case, I'm trying to use a web service on a apache server + django (the service was written by myself). I was having the same output as you: Chrome says it was cancelled while FF does it okay. If I tried to access the service directly on the the browser instead of ajax, it would work as well. Googling around, I found out that some newer versions of apache weren't setting the length of the response correctly in the response headers, so I did this manually. With django, all I had to do was:

response['Content-Length'] = len(content)

If you have control over the service you are trying to access, find out how to modify the response header in the platform you are using, otherwise you'd have to contact the service provider to fix this issue. Apparently, FF and many others browsers are able to handle this situation correctly, but Chrome designers decided to do it as specified.

If you're using Chrome you can't see enough information in the standard Chrome networking panel to determine the root cause of a (canceled) request.

You need to use chrome://net-internals/#events which will show you the gory detail of the request you are sending - including hidden redirects / security information about cookies being sent etc.

e.g. the following shows a redirect I wasn't seeing in the network trace - caused by my cookies not being sent cross sub-domain:

t=1374052796448 [st=  1]   +URL_REQUEST_START_JOB  [dt=261]
                            --> load_flags = 143540481 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VALIDATE_CACHE | VERIFY_EV_CERT)
                            --> method = "GET"
                            --> priority = 2
                            --> url = "https://...."
...
t=1374052796708 [st=261]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                --> HTTP/1.1 302 Moved Temporarily
                                    Content-Type: text/html
                                    Date: Wed, 17 Jul 2013 09:19:56 GMT
...
t=1374052796709 [st=262]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=0]
t=1374052796709 [st=262]        CANCELLED
t=1374052796709 [st=262]   -URL_REQUEST_START_JOB
                            --> net_error = -3 (ERR_ABORTED)

If anyone else runs into this, the issue we had was that we were making the ajax request from a link, and not preventing the link from being followed. So if you are doing this in an onclick attribute, make sure to return false; as well.

I had this issue with a particular 3G network.
It would always fail on DELETE requests with net_error = -101 in chrome://net-internals/#events.

Other networks worked just fine so I assume there was a faulty proxy server or something.