What can cause Chrome to give an net::ERR_FAILED on cached content against a server on localhost?
Solution 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.
Solution 2
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
Solution 3
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
Solution 4
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/
Solution 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.
Mason Wheeler
A lifelong programmer who's been coding in Delphi since its initial release and currently makes a living at it.
Updated on March 21, 2021Comments
-
Mason Wheeler about 3 years
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 ofXmlHttpRequest
requests fail withnet::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-relatedThis 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?