What can cause Chrome to give an net::ERR_FAILED on cached content against a server on localhost?

Question

I'm building a web server and trying to test things. The server is running on localhost:888, and the first time I load the web app, everything works. But if I try to reload the page, a bunch of XmlHttpRequest requests fail with net::ERR_FAILED. By putting breakpoints in the server code, I can verify that the requests are never actually coming in.

This isn't a connection failure, as the connection succeeds the first time. The fact that it succeeds once and then fails later implies that it might be caching-related, but there's nothing in the server code that sets the cache-control header. So I tested it by putting the server up on an actual web server. The first time, everything had to take its time loading; the second time, it all loaded instantly, so this is definitely cache-related

This is a custom server running on top of http.sys (no IIS), and it appears that things are getting cached by default and then failing to load from it on subsequent runs, but only when my server is running on localhost; on the Web, it works fine. As near as I can tell, net::ERR_FAILED is a generic "something went wrong and we've got no useful information for you" message in Chrome, so I'm kind of stuck here. Does anyone know what could be causing this?

Endoenzyme

One possible reason is that your AppCache Manifest does not allow it. I suppose there may be many other reasons as well (CORS?). – Squalor

Do you have any CORS issues? Please try to disable web security in chrome and see if the problem persist. To disable use smt like: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security from command line. – Ylem

Are you running AdBlock? It has been known to cause errors like these on local environments. – Malamud

@DennisPriebe: Nope. No AdBlock here. – Endoenzyme

Answer 1

I run into similar problem. I have copied request as fetch in Network tab in devtools.

Then I have run it in browser dev console. There I could read description of the error about CORS. After setting cors on the api server, it worked.

You have to paste the fetch command into the dev console of the same origin and NOT accidentally e.g. open it from stackoverflow.

Barque

I kept getting this error until I opened the same app URL in my browser as the API I was testing and had the DevTools console in that same window, then it started working each time. – Fifth

Answer 2

There is only one way to get to the bottom of these types of error

In chrome use chrome://net-export/ in a tab, then record the session in another and debug with https://netlog-viewer.appspot.com/#import which allows you to view the output in a more readable format.

We recently found an ERR_FAILED down to the socket being closed because of a proxy authentication issue on the clients network.

This can also be useful reference once you've got the error code from the above chrome://network-errors/

Sundberg

Answer 3

Another cause is, when you use withCredentials: true (sending cross origin cookies) for XHR calls, you are not allowed to set Access-Control-Allow-Origin: *, but have to provide a specific domain!

Sadly, you cannot use a list of domains here, because no browser supports this official standard. But several frameworks, like Spring, allow you to set a whitelist configuration, which then is matched on request.

See also:

• CORS: Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true
• Header in the response must not be the wildcard '*' when the request's credentials mode is 'include'
• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials

Gosselin

Answer 4

One very important and un-loved comment in this set of answers is, "Look at your CORS headers." I had a problem much like this, and it gave me this error with some prodding. No data in my Apache logs, but I noticed that we were calling a secondary URL and getting no response for that secondary URL.

Chrome didn't initially call it a CORS issue, but lack of response caused me to dig into our Apache settings and change the allowable CORS source header.

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
        Header set Access-Control-Allow-Origin "https://our-site.com"
        Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
        Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"

</Directory>

This answer may not apply to YOUR situation, but it applied to my net::ERR_FAILED

Aachen

Answer 5

One possible reason is that you write your AppCache Manifest wrong. For example: in you /a/b/cache.html file you refer the cache.appcache Manifest file, but in cache.appcache file you announce like:

CACHE:

/cache.html

which is wrong.

you should write:

CACHE:

/a/b/cache.html

hope this can help you.

Eject

Answer 6

In my case installing an SSL certificate fixed the issue.

Shantell

Answer 7

Another potential cause is the request being handled by a service worker that runs into some sort of trouble. In this case it's worth checking the service worker console in the dev tools to see if there's an error message there.

Rust

important notice - a lot of people don't know this – Shantell

Answer 8

Add "proxy": "http://localhost:port_number/" at the last line in package.json and mode: 'same-origin' in the request body at the client-side. For example,

fetch('login', {
      method: 'post',
      mode: 'same-origin',
      headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        username: username,
        password: password,
      })
    })

Hungnam

Answer 9

I ran into this error on my localhost (on a monday morning) when requesting one of my virtual hosts. Turned out I still had a unfinished debugging action running (unfinished business from my friday afternoon :) ) on another virtual host which blocked Apache from serving the files for the other request. This resulted in the net::ERR_FAILED error in my browser console.

Hope this might be helpful for others ending up here.

Cease

Answer 10

If using node, make sure your CORS headers are added before the route. IE

app.use(function(req, res, next) {
    res.header("Access-Control-Allow-Origin", "*");
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
    next();
});

app.get('/route.htm', function (req, res) {
    res.sendFile( __dirname + "/" + "route.htm" );
});

Instead of the other way around putting app.use after.

Pyroxene

Answer 11

This happened to someone on Mac OS / Chrome but not on Safari. And seems to have emerged recently (i.e. - likely not from a code deploy... Maybe a Chrome update?). I can't reproduce it on other computers with Chrome. Restarting Chrome and the computer didn't help.

I didn't notice anything strange in Extensions and they said they hadn't installed anything new.

Posting in case there is a newly emerging issue on Chrome.

Ultimo