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

Describe the bug

When making a request to my API, the catch block has a generic "Network Error" message, but when checking in the network inspector the request got a response code 413. This causes my users to incorrectly report that 'the website thinks i dont have a solid internet connection'. I suspect this happens for other codes too because this has been going on for a while.

To Reproduce

Make a request with a very large payload to trigger a 413 response

Expected behavior

The catch block should have the response code

Environment

Additional context/Screenshots

axiosInstance
    .post("/results/add", {
      result: completedEvent, //this is very big
    .then((response) => {
      // handle response
    .catch((e) => {
        console.log(e);
        //this console logs Error: Network Error
        // at createError (monkeytype.js:formatted:35086:25)
        // at XMLHttpRequest.handleError (monkeytype.js:formatted:34457:28)
    });

My axios instance code:
https://github.com/Miodec/monkeytype/blob/master/src/js/axios-instance.js

We also see an increased number of Network Errors in our app. It must be iOS related, the logs shows only: iPhone, Mac, iPad (90% with iOS 14.X) devices for it.
Downgrading to 0.24.0 now to check if it fixes the error.

Edit: same issue with 0.24.0
Exception:
Error: Network Error
at apply(./node_modules/core-js/internals/wrap-error-constructor-with-cause.js:34:66)
at Error(./node_modules/core-js/modules/es.error.cause.js:28:43)
at createError(./node_modules/axios/lib/core/createError.js:16:19)
at apply(./node_modules/axios/lib/adapters/xhr.js:117:14)
at r(./node_modules/@sentry/browser/esm/helpers.js:73:23)

Edit2: the issue startet on January 21. with axios 0.21.4. We did no updates or changes at this day, so i highly suspect it is caused by an iOS update/security patch. I wasn't able to reprocude it on our iOS test devices so far.

Tagging the axios team @rubennorte @mzabriskie @emilyemorehouse @jasonsaayman @nickuraltsev

Any chance you could have a look into this? I feel like this is quite important, since it makes it impossible to do proper error handling, makes it harder to debug and confuses users.

@manugch @Miodec do you have any DNS ad blockers? I disabled my AdGuard and now it works fine. Can you check any any blockers/vpn?

No Adblockers. I also see the error happening on visitor devices in our sentry logs, over 112 iOS devices by now who crashed with that unhandled "Network Error".
It affects only iOS devices as I said before Mac, iPhone, iPad mostly iOS/Safari 14.1.X

@manugch @Miodec do you have any DNS ad blockers? I disabled my AdGuard and now it works fine. Can you check any any blockers/vpn?

Tested without adblock - same thing.

I am seeing the exact same issue. A generic error saying Error: Network Error with no other information when getting 403s. According to the docs, the error should still include the response code and headers, but it doesn't.

Looking at the code, there seems to be a catch all in the XHR adapters https://github.com/axios/axios/blob/master/lib/adapters/xhr.js#L118

It's not there in the HTTP adapter which will give the correct error so you may want to switch to that

I think it's because the XHR spec doesn't give any clue about the error , so I don't think it can be fixed. As your then dependant on the browser implementation to trigger the .onError only if HTTP code = 0, and it seems some will trigger this with codes in the 400 range

I think it's because the XHR spec doesn't give any clue about the error , so I don't think it can be fixed.

So, why does the console correctly show errors like ERR_FAILED 413 in this case, or CONNECTION_REFUSED or SSL_CERT_DATE_INVALID that I ran into in other cases? All of them give Network Error , but somehow show up correctly in the console...

Pretty sure using HTTP is not the best solution as its not supported in every browser (webpack replaces it with xhr)

EDIT: Right.. Im assuming its related to the // Real errors are hidden from us by the browser comment....

Alright, I figured things out (im still learning so some details could be wrong)

Basically, there is no way around it. Axios is just a wrapper for XMLHttpRequest (just realised that's where the XHR acronym comes from) to make it a bit easier to use and less complicated to write. Axios gives us a Network Error because xhr itself doesn't give us any info about the error . You can see for yourself by doing a simple request to an endpoint that doesn't exist:

const oReq = new XMLHttpRequest();
oReq.addEventListener("error", (e) => {
  console.log(e);
});
oReq.open("GET", "http://localhost:5005/");
oReq.send();

The console.log will give us (drumroll please):
Absolutely nothing :)

However, the console error will show GET http://localhost:5005/ net::ERR_CONNECTION_REFUSED (still don't understand why the error is in the console but not in the event listener parameter)

So either way, this is not the fault of Axios. The only fix here that was mentioned by @Tofandel is to switch to the HTTP adapter at the expense of some compatibility - I don't know how big this expense is exactly. Axios uses Node's HTTPS module in its HTTP adapter and I'm not sure yet what things like webpack will replace it with. If I remember ill update this comment with my further findings.

I am just here to add information, not reopening this issue. Axios in browsers will use XHR. My application is a consumer internet application and I can not think of anything other than XHR which can work for most browsers. Also, upgrading to version 0.26 has significanty reduced these errors for me.

So are there any links related issues if it is a browser issue?

Is this only in Safari browsers or also happens in Google Chrome/Firefox etc?
Is there a browser update that fixes it?

Suspect my iOS users are having this problem, I'm using latest Axios version 0.27.2.
I've also seen it bomb out on android phone with google chrome however (not sure if related did not have adb inspector connected).

In my case, the CORS was blocking the frontend from acessing the backend.
My Solution: Add this in the server-side:

                 Using npm, install 'cors':
                  npm i cors
                  And add this lines to the code:
                  let cors = require("cors");
                  app.use(cors());
  rodrigofbm, vfreguglia, MissCryptoSarcasm, devDoubleH, adarsh-gupta101, Kshitiz1403, YaoHure, PandaPandaDev, tcs-mkrishnan, waqaswithshare, and 17 more reacted with thumbs down emoji
  ShalemOrtega and devmatheuus reacted with hooray emoji
  Prasham2407, ushnuel, and hakeem0114 reacted with confused emoji
  devmatheuus reacted with heart emoji
    All reactions
          
Hello to Everyone.

I just want to let you know that after searching for a solution for two days, I was able to solve my error.

Since the proxy was the source of the issue, I must configure a proxy in the package.json file, and I had to follow these instructions in the function that used Axios:

try { await axios.post("user/login", formData).then((res) => { console.log(res.data); }); } catch (error) { console.log(error.response.data.message); }

and in package.json file need to add a proxy:

"proxy": "http://localhost:<SERVER_PORT_NUMBER>"

for better understand check this documentation https://www.jamesqquick.com/blog/configure-proxy-in-react/
          
I had exactly the same issue. Front-end I was using axios and back-end I was using .net core WebAPI. The solution was at the side of the back-end:

    app.UseCors((g)=>g.AllowAnyOrigin());
I had exactly the same issue. Front-end I was using axios and back-end I was using .net core WebAPI. The solution was at the side of the back-end:  app.UseCors((g)=>g.AllowAnyOrigin());
Is this setting to allow cross-domain? It doesn't seem like this is working. It is more convenient to set cross-domain in Nginx, and it has nothing to do with it.
Make a request with a very large payload to trigger a 413 response
Since somebody mention about the 'large payload', does anyone have re-produce with it, and which size would be large in this case?
You can probably replicate this. Set up a web server, say Nginx, and esnure it can only receive a 5MB POST request. Send this server a payload more than 5MB and you will receive this error. However, I am not clear what is Axios' role in all this... 😕
          
#4420 (comment)
Probably the original issue posted here has to do with how CORS is handled by the browser. Looking at your network console the API endpoint is allowing your origin to make the request since OPTIONS request is successful and (taking a guess here) they are also succeeding with small file POSTS and not the bigger than threshold size ones.
That leads me to think that  the  content too large 413 is probably served by  (
a reverse proxy like Nginx  sitting in the middle ( which is where the response is originating from and not your API). Is it possible that you have not allowed the origin as a part of the error response(s) originating from Nginx.  If yes chrome is probably disallowing the response from being read by your app. You can resolve this by providing Access-Control-Allow-Origin header as a part of the 413 response after which axios will receive the response ( you will need to have access to the reverse proxy or the likes in the middle to add this header).
A middleware (in your API) that intercepts the request and does not set the 'Access-Control-Allow-Origin'  headers appropriately while providing the error response. If not present chrome is probably disallowing the response from being read by your app (The browser/chrome receives the entire response as can be seen from the network console).
          
Here's what worked for us
We wanted our nginx server to handle request timeouts (504), so we configured a proxy_read_timeout 480s and added an error handler:
    error_page 503 /503.json;
    location = /503.json {
        add_header 'Access-Control-Allow-Origin' '*' always;
        return 503 '{"error":{"code":503,"message":"Service Unavailable"}}';
Note that we have to add the correct CORS headers since it's a cross domain request, and we add the always since we want the headers for 50Xs a not just 20X-30Xs .
add_header 'Access-Control-Allow-Origin' '*' always;
It's not enough to add CORS handling to your application code in this case, since it's nginx that's responsible for setting the correct header here.
          
Hi Everyone, I found the problem for me, I already had cors enabled but I was still facing axios network error, after a little bit of research I found out that for a mobile device localhost is 10.0.2.2:{PORT}. I still kept 127.0.0.1:{PORT} at my node js backend and my API in react native started working.
React Native 18.2
Chrome

Pls I throws me an error , som1 knows why ocurs that and how i fix it ?
Hey yosseferrazik ;

Firstly you have to use a function for async request in useEffect. But this is not resolve your problem. Also I have the same problem.
You can try the add below line add AndroidManifest.xml file <application tag. I think you will be solve you problem. But  I faced same error now. Did you resolve ?

android:usesCleartextTraffic="true"
@manugch @Miodec do you have any DNS ad blockers? I disabled my AdGuard and now it works fine. Can you check any any blockers/vpn?
I had the same problem. I'm using Brave browser. I disabled the shields and it worked.
          
I faced the same issue even after installing cors. I was able to fix it by making sure the cors code was above my route declaration. Code below.

Before:
app.use("/api/messages", messagesRoutes); 
app.use(cors());
After:
app.use(cors()); 
app.use("/api/messages", messagesRoutes);
Hope this helps