Is 4xx and 5xx network errors?

Question

I have a node server that basically reads a component from a specific path, executes the code, and returns the data to the other server.

Sometimes during the code execution of the component, I get a 403 response.

Error:

ApolloError: Response not successful: Received status code 403

I'm using .catch() to catch the 403 response but it's not helping and there are frequent pod crashes due to the 403.

I have checked this StackOverflow answer - Fetch: reject promise and catch the error if status is not OK?

It mentions that

Since 4xx and 5xx responses aren't network errors, there's nothing to catch

Is this correct?

If the above statement is true, can it be handled like the below:

app.use((req,res) => {
   res.status(403).send('');
})

4xx and 5xx errors are not network issues. 4xx is (generally) caused by an issue in the request data coming from the client, and 5xx are unexpected errors when the code runs on the server to handle the request. More info at [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses). In this specific case a 403 error means that the resource benig requested needs the client to be authenticated, and you haven't sent any authentication data in the request, or if you have, it's invalid. — Rory McCrossan, Jan 23 '23 at 14:46
*"I'm using .catch() to catch the 403 response"* Where? In what code? — T.J. Crowder, Jan 23 '23 at 14:48
Your questions seems a tad mixed up, you talk about 403 from a client perspective, and then show an express handler that's server side. — Keith, Jan 23 '23 at 14:52

T.J. Crowder · Accepted Answer · 2023-01-23T14:58:24.387

Is 4xx and 5xx network errors?

No, they're HTTP error responses, successfully transferred from the server to the client via the network.

I'm using .catch() to catch the 403 response

I assume you mean with fetch given the question you linked to. This is a common issue (a footgun in my view) with using the fetch API. fetch only rejects its promise on network errors, not HTTP errors. So, it will reject its promise if it can't contact the server. It won't if it successfully contacts the server and receives an HTTP error response.

The answers to the question you link (such as this one) and my linked blog post above describe how to handle this using a common path for network and HTTP errors: When you first get the Response object, check its ok property and throw if it's not true, then handle rejection in a common rejection handler.

But reiterating in case those resources disappear (unlikely, but answers are supposed to be self-contained), using JSON as an example, I'll usually have something like this in my codebase on a project:

async function fetchJSON(...args) {
    const response = await fetch(...args);
    if (!response.ok) {
        // Network was fine, but there was an HTTP error
        throw new Error(`HTTP error ${response.status}`);
    }
    return await response.json();
}

I do that because the vast, vast, vast majority of the time, the code doing the fetch doesn't care whether there was a network error or an HTTP error, it just cares that the fetch (and associated JSON parsing) did or didn't work.

Is 4xx and 5xx network errors?

1 Answers1