$httpBackend changing all zero status codes to 404 forbids identifying a down server

[swallez]

Commit 28fc80b forcefully changes status code zero to 404 without considering the protocol.

Because of this, it's not possible to distinguish at the application level between a server that did not respond (zero) and a non existing resource (404). Please consider reverting this commit, or narrow the status code check so that 404 is only returned for the Android file protocol.

[stefansundin]

Agreed! +1

[8bitDesigner]

Yeah, I don't like showing "Error could not do #{ish}" whenever the user navigates away from my page during a request.

[geirgp]

Great, thanks for creating the issue!

[jimleroyer]

+1 Throwing a 404 is misleading in multiple ways. The application assumes that:

• The server responded and is up.
• The server resource does not exist.

I'd vote for a revert or a better fit for the response code such as 503 or 522 (latter is non-standard and vendors specific though).

It's a bit tricky to handle connection timeout in a standard way using response codes because these response should be sent by the server. But on connection timeout, we don't get any response. So AngularJS injects a response code, as if the server returned it, but this never happened.

[raboof]

+1 I'd love a better way to find out the details about connection errors that are not the result of a HTTP response code sent by the server - such as indeed timeouts, host not found, destination unreachable, connection refused etc.

[spalger]

Seems to me that status = (status === 0 && response) ? 200 : status would keep #1356 fixed and prevent misleading 404 responses. Will look into submitting a PR.

[pkozlowski-opensource]

This is duplicate of #6074

[raboof]

The desire expressed above to be able to distinguish between 'host not found', 'destination unreachable', 'connection refused' etc isn't in #6074, but that seems like an XMLHttpRequest limitation anyway - so not something that we can fix in Angular.js