axios should not throw on valid HTTP responses

Created on 9 Oct 2016 · 3Comments · Source: axios/axios

Why does axios throw on status < 200 || status >= 300 ? see defaults.js#L84
An HTTP error 500 means we reached the server and even got a valid response using the http protocol.

From an application point of view an HTTP error 500 might be considered an exception, but this is at a different abstraction level and entirely unrelated to the HTTP abstraction.

In order to be forward compatible with the upcoming fetch specification, I think it is important axios would not throw in case of valid HTTP responses.

The fetch specification specifies a response.ok property, so that the application developer can easily identify the result of the HTTP operation, I believe a similar approach could be useful for axios.

Please see here for more details on the fetch spec:
https://fetch.spec.whatwg.org/#dom-response-ok
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

Source

helmus

👍9

Most helpful comment

Correct, but my point is that this shouldn't be the default. In fact this shouldn't even be configurable.

helmus on 10 Oct 2016

👍7 👎6

All 3 comments

I think you can use validateStatus config option to always resolve when there is a server response. from the docs:

// `validateStatus` defines whether to resolve or reject the promise for a given
// HTTP response status code. If `validateStatus` returns `true` (or is set to `null`
// or `undefined`), the promise will be resolved; otherwise, the promise will be
// rejected.
validateStatus: function (status) {
  return status >= 200 && status < 300; // default
}

omasback on 10 Oct 2016

❤2 👍2

Correct, but my point is that this shouldn't be the default. In fact this shouldn't even be configurable.

helmus on 10 Oct 2016

👍7 👎6

We understand your concern but Axios doesn't mean to replace fetch nor mimic its behaviour. We don't even use it as an adapter to make the calls (we stick to XHR for the moment).

Axios tries to be as configurable as possible providing the defaults that most people will use. In this case people tend to verify the status code right after a response from the server. E.g.:

fetch(url).then(verifyStatus).then(...);

That's why packages like fetch-check-http-status exist.

We want to avoid that structure that repeats so frequently. If you want to resolve with any valid response from the server you can always set validateStatus: false.