Why is errorStatus 400+ considered a success?

[lordgreg]

Hi.

I've been trying to implement the http interceptor exactly as you've explained to another person in #89 .

I've created my own inherited class and updated send function. In any case (with using my own class or just running httpClient.get), where httpClient is new Client();,

Running this command:

httpClient
            .get('https://google.com/awefwefsfuhsdlk')

returns success.

Why is that so? Why do I not land in catchError? That also means, if trying to use my own interceptor:

Future<StreamedResponse> send(BaseRequest request) {
    return _inner.send(request);
     .catchError((onError) {
      // in case of non 200 statuses, we will NEVER land here.
      return onError;
    });

What is then the correct way of implementing error response interceptor?

[zoechi]

Exceptions (what catchError catches) is about exceptional behavior.
The code is also called "status code" not "error code".
Status codes different from 200 are normal https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
1xx, 2xx, 3xx are in no way errors.
5xx informs about an error somewhere else, only very few from 4xx are actual errors, the others are also just status information.

[lordgreg]

Thank you for your response @zoechi. Correct, as you've said, only few of 4XX codes are considered errors. My question was probably not clear enough, but at least that means the implementation returns success in case of client errors (as you've found out from Wikipedia article).

I think 404 is nothing else as error. Opening a network tab in developer options in your browser will also suggest, hitting 404 is considered to be an error.

Citing W3 standard file points into exactly same direction:

10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.

And therefore is the implementation of continuing in case of 4XX for specific numbers wrong.

[zoechi]

I don't see why 404 would be an error. The client makes a request and responds that the connection could not be established. That's quite a common request/response scenario, like

Caller: Operator please connect me to 12345.
Operator: The number 12345 does not exist (404).
Telephone: Exception - shutting down. Please call your telecom service team to re-enable.

Don't you think the 3rd line is redundant. That's how I see an exception for 404.

[natebosch]

The interceptor needs to decide which status codes it wants to treat as errors - it isn't up to the HTTP package to turn results into exceptions based on their status code.

You could write an interceptor that will check response.statusCode and throw an exception for certain ranges if you like.