What does status=canceled for a resource mean in Chrome Developer Tools?

If you use axios it can help you

// change timeout delay: instance.defaults.timeout = 2500;

https://github.com/axios/axios#config-order-of-precedence

Here is another case of request being canceled by chrome, which I just encountered, which is not covered by any of answers up there.

In a nutshell
Self-signed certificate not being trusted on my android phone.

Details
We are in development/debug phase. The url is pointing to a self-signed host. The code is like:

location.href = 'https://some.host.com/some/path'

Chrome just canceled the request silently, leaving no clue for newbie to web development like myself to fix the issue. Once I downloaded and installed the certificate using the android phone the issue is gone.

If you make use of some Observable-based HTTP requests like those built-in in Angular (2+), then the HTTP request can be canceled when observable gets canceled (common thing when you're using RxJS 6 switchMap operator to combine the streams). In most cases it's enough to use mergeMap operator instead, if you want the request to complete.

I have embedded all types of font as well as woff, woff2, ttf when I embed a web font in style sheet. Recently I noticed that Chrome cancels request to ttf and woff when woff2 is present. I use Chrome version 66.0.3359.181 right now but I am not sure when Chrome started canceling of extra font types.

We had this problem having tag <button> in the form, that was supposed to send ajax request from js. But this request was canceled, due to browser, that sends form automatically on any click on button inside the form.

So if you realy want to use button instead of regular div or span on the page, and you want to send form throw js - you should setup a listener with preventDefault function.

e.g.

$('button').on('click', function(e){

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

For me 'canceled' status was because the file did not exist. Strange why chrome does not show 404.

It was as simple as an incorrect path for me. I would suggest the first step in debugging would be to see if you can load the file independently of ajax etc.

The requests might have been blocked by a tracking protection plugin.

It happened to me when loading 300 images as background images. I'm guessing once first one timed out, it cancelled all the rest, or reached max concurrent request. need to implement a 5-at-a-time

One the reasons could be that the XMLHttpRequest.abort() was called somewhere in the code, in this case, the request will have the cancelled status in the Chrome Developer tools Network tab.

In my case, it started coming after chrome 76 update.

Due to some issue in my JS code, window.location was getting updated multiple times which resulted in canceling previous request. Although the issue was present from before, chrome started cancelling request after update to version 76.

I had the same issue when updating a record. Inside the save() i was prepping the rawdata taken from the form to match the database format (doing a lot of mapping of enums values, etc), and this intermittently cancels the put request. i resolved it by taking out the data prepping from the save() and creating a dedicated dataPrep() method out of it. I turned this dataPrep into async and await all the memory intensive data conversion. I then return the prepped data to the save() method that i could use in the http put client. I made sure i await on dataPrep() before calling the put method:

await dataToUpdate = await dataPrep(); http.put(apiUrl, dataToUpdate);

This solved the intermittent cancelling of request.

I had an a tag inside a div tag. div had onclick="location='http://mydestination.org/'" and a tag had the same URL in href. That caused the target page to be loaded two times and the first load was canceled by Chrome.

In my case the cause of the problem was yet another one.

My application is sitting behind a proxy, and Chrome requests were being sent with the If-Modified-Since HTTP header. When this header is present the exepcted behavior is:

the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the request has not been modified since, the response will be a 304 without any body;

The Proxy was failing to meet this expectation, responding with a 304 status code but a non-empty body, thus causing the request to be cancelled.

After fixing the proxy behavior requests worked like a charm.

Content Security Policy headers for me! You can quickly rule out this possibility by checking the Chrome Dev Tools Console, if it's CSP problems there will be errors showing in the console. In .Net you can fix this either by adding headers in the web.config file or in code.

Refused to send form data to 'https://www.mysite.mydomain/' because it violates the following Content Security Policy directive: "form-action 'self' *.otherdomain www.thirdparty.co.uk".

Here's the web.config fix for the above error:

<cspConfiguration>
        <directives>
            <directive name="form-action" allowedSources="'self' *.mydomain>
            </directive>
        </directives>
</cspConfiguration>

in strict point of view of Angular :

it happens when, you're not able to properly break at the code level.

suppose, request1 is out, and its response also came, after that, nested request2 also went out and its response also came, and directly we're breaking out of the loop, without properly destroying the subscription of request1,

at that time, it happens