Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeError: NetworkError when attempting to fetch resource - firefox issue #310

Closed
jcimoch opened this issue Apr 11, 2016 · 22 comments
Closed

Comments

@jcimoch
Copy link

jcimoch commented Apr 11, 2016

Hi, I have simple function for logout that looks like this

public logoutHandler() {
    fetch('/logout', <RequestInit>{
      method: 'get',
      credentials: 'include'
    }).then((response) => {
      console.log(document.cookie);
      window.location.href = '/login';
    });
  }

It is workin in chrome but in firefox I get "TypeError: NetworkError when attempting to fetch resource.1 (unknown)". Client side app is on the same server as backend, I'm using https connection with self-signed cert, could it be the issue?

@dgraham
Copy link
Contributor

dgraham commented Apr 11, 2016

Firefox contains a native fetch implementation and does not use this polyfill code. You can use the Network tab in Firefox's web console to debug the request and response.

@ariden83
Copy link

On chrome, I've got "TypeError: Failed to fetch"
On firefox, the same "TypeError: NetworkError when attempting to fetch resource"
..

@jstoja
Copy link

jstoja commented Jun 26, 2017

Have you check errors like CORS?

@billytianlan
Copy link

@ariden83 did you figure out what was causing the errors? I'm seeing the same issues in isolated cases

@fabdarice
Copy link

Can we reopen this ticket?
I'm seeing the same error, but only on Firefox.
Also, nothing shows up in the Network tab.

@ncaq
Copy link

ncaq commented Sep 6, 2017

There maybe relational link.

Fetch api not working in firefox addon : firefox
1346447 - Fetch api not working within addon

@ganeshangler
Copy link

I'm seeing the same error,except chrome

@iamsoorena
Copy link

I have the same exact issue. everything is fine in chrome but firefox caches wrong fetch response. and the worst of all is that it caches this error as response of that particular endpoint of my api for a LONG time.

@jomo
Copy link

jomo commented Dec 22, 2017

Having the same issue when I have network.http.referer.XOriginPolicy set to 1 ("send a referrer only when the base domains are the same"). Is that supposed to happen? I'm quite sure the base domain of localhost matches the base domain of itself :)

@manoharreddyporeddy
Copy link

Related issue.

I was accessing Function app, via Logic app, when I got the above error.

Following worked for me:

  1. Function app > Platform features tab > API > CORS > Allowed Origins > (remove all, Save)
  2. Function app > Platform features tab > API > CORS > Allowed Origins > * > Save (that is add * and save)
  3. Function app > Overview tab > Restart

Hope that helps.

@aguayUmbt
Copy link

@manoharreddyporeddy function app > platform features tab etc
what are those?

@manoharreddyporeddy
Copy link

@aguayUmbt they are menu/sequence of operations to be done in the Azure portal

@niranjanreddy891
Copy link

@jcimoch, I am having the same issue. Please tell me how to debug it. :)

@sangxxh
Copy link

sangxxh commented Jan 16, 2019

For those who are writing Firefox addon, the solution here helped me, I have to add "*://localhost/*"
to permissions key in manifest.json:


  "permissions": [
    "storage",
    "*://localhost/*"
  ],

Chrome just works without the need to add this permission...

@ghost
Copy link

ghost commented Feb 19, 2019

If anyone comes across this, I had the same error in Firefox (but with a different application) and it turns out it was because the (self-signed) SSL certificate I was using on the server was not trusted in Firefox. I added the self-signed root CA to Firefox and all was well.

@thehme
Copy link

thehme commented Feb 19, 2019

In our case, the solution was not using the wild card for Access-Control-Allow-Origin on the server side, instead of the wild card, our settings look like this:

res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
res.setHeader("Access-Control-Allow-Headers", "Authorization, Cache-Control, Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers");

@Hervera
Copy link

Hervera commented Mar 17, 2019

Check if you are using http or https on your server. For me, the error was coming online with heroku server because they use https while in local machine I was using http and it was working.
After choosing https on Heroku for my endpoints, it also worked

@x011
Copy link

x011 commented Aug 15, 2019

I managed to solve the problem by monitoring the headers returned by github used on the demo page.
Since I'm using a python webserver, they look something like this:

self.send_header("Access-Control-Allow-Origin", "*")
self.send_header("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
self.send_header("Access-Control-Allow-Headers", '*');
self.send_header("Status", "200 OK")
self.send_header("Vary", "Accept")
self.send_header('Content-Type', 'application/octet-stream')

Hope it helps.

@rohanaceres
Copy link

For me, Swagger UI for some reason crashes when I use examples that consume multilanguage resource files. So I removed the examples from Swagger config and Swager UI started working properly again - of course, without examples.

@sebastian-palma
Copy link

Tried in a Rails 6 only-api app with CORS enabled, using NGROK and no luck.

Tried instead

{
  ...
  "permissions": [
    "storage",
    "<all_urls>"
  ]
}

and got it working.

@Leslie-Wong-H
Copy link

Same issue. But what is particular in my situation is that I need to fetch a blob url, like "blob:https://images.google.com.hk/9143673d-b976-4416-b29c-85ce48a77da6".

However, if I declare manifest.json as

{
   ...
   "permissions": [
       "blob:*",
    ]
} 

Firefox does not recognize it, and throws a warning message, "Reading manifest: Warning processing permissions: Error processing permissions.1: Value "blob:" must either: must either [must either [be one of ["clipboardRead", "clipboardWrite", "geolocation", "idle", "notifications"], be one of ["bookmarks"], be one of ["find"], be one of ["history"], be one of ["menus.overrideContext"], be one of ["search"], be one of ["topSites"], be one of ["activeTab", "tabs", "tabHide"], be one of ["browserSettings"], be one of ["cookies"], be one of ["downloads", "downloads.open"], be one of ["privacy"], be one of ["webNavigation"], or be one of ["webRequest", "webRequestBlocking"]], be one of ["alarms", "mozillaAddons", "storage", "unlimitedStorage"], be one of ["captivePortal"], be one of ["browsingData"], be one of ["devtools"], be one of ["identity"], be one of ["menus", "contextMenus"], be one of ["normandyAddonStudy"], be one of ["pkcs11"], be one of ["geckoProfiler"], be one of ["sessions"], be one of ["urlbar"], be one of ["contextualIdentities"], be one of ["dns"], be one of ["activityLog"], be one of ["management"], be one of ["networkStatus"], be one of ["proxy"], be one of ["nativeMessaging"], be one of ["telemetry"], be one of ["theme"], or match the pattern /^experiments(.\w+)+$/], or must either [be one of ["<all_urls>"], must either [match the pattern /^(https?|wss?|file|ftp|*)://(*|*.[^*/]+|[^*/]+)/.$/, or match the pattern /^file:///.$/], or match the pattern /^resource://(*|*.[^*/]+|[^*/]+)/.$|^about:/]"

Maybe the pattern /^(https?|wss?|file|ftp|*)://(*|*.[^*/]+|[^*/]+)/.*$/ can provide some hints, but useless for a blob URL. 😞

I don't need to declare any permission about blob URL at chrome.

All right, it looks like <all_urls> is the only way.

@MihailYotov
Copy link

I had this problem and turned out that someone had put redirection (window.location = '/') not in the promise's resolve function, but immediately after the fetch call, so the application was aborting the call and redirecting to the index.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests