Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

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

Closed
swallez opened this issue Feb 6, 2014 · 8 comments

Comments

@swallez
Copy link

swallez commented Feb 6, 2014

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.

swallez referenced this issue Feb 6, 2014
Android 4.1 stock browser also returns status code 0 when
a template is loaded via `http` and the application is cached using
appcache.

Fixes #1356.
Closes #5547.
@stefansundin
Copy link

Agreed! +1

@8bitDesigner
Copy link

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

@geirgp
Copy link

geirgp commented Feb 7, 2014

Great, thanks for creating the issue!

@jimleroyer
Copy link

+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
Copy link

raboof commented Feb 16, 2014

+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
Copy link

spalger commented Feb 25, 2014

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
Copy link
Member

This is duplicate of #6074

pkozlowski-opensource added a commit to pkozlowski-opensource/angular.js that referenced this issue Mar 1, 2014
PR angular#5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://

Fixes angular#6074
Fixes angular#6155
@raboof
Copy link

raboof commented Mar 3, 2014

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

pkozlowski-opensource added a commit that referenced this issue Mar 14, 2014
PR #5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://

Fixes #6074
Fixes #6155
pkozlowski-opensource added a commit that referenced this issue Mar 14, 2014
PR #5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://

Fixes #6074
Fixes #6155
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
10 participants