fix(angular.js): wrong $httpBackend status code

[c0rrupt]

If I run html document as a file in browser (e.g. file:///index.html), then all ajax responses have a protocol "file" (and therefore response status code can be 200 or 404)

(protocol == 'file') ? (response ? 200 : 404)

locationProtocol has higher priority in completeRequest function.

It's critical in mobile hybrid applications which use angularjs (index.html run from local filesystem)

[mary-poppins]

Thanks for the PR!

• Contributor signed CLA now or in the past
  • If you just signed, leave a comment here with your real name
• PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[rtpm]

Can you please move this issue into the 1.2 milestone ? Angularjs is being used by more phonegap/cordova users every day and this issue makes angular working with remote data impossible.

[lord2800]

I'm happily using Angular 1.2rc3 on phonegap right now with no issues--I also don't use file:// urls, I use relative urls; that may make all the difference.

[rtpm]

@lord2800 I also use relative paths and the problem exists. Have you tried with $http.post() with backend returning HTTP_400 for example ?

[lord2800]

Ah, I haven't tried POSTing to myself. I can give that a try.

[damrbaby]

+1, thank you @c0rrupt for this fix, this is a major bug, and should be in 1.2 release.

Currently if you are using phonegap/cordova (or anything that serves your app over a file:// protocol) and $http with a backend that responds with a non-200 status code (e.g. 400-500) with a response it will be considered a 200 status code, and the success function will be called.

[ADmad]

@damrbaby Yup I am having the exact same problem you describe. In my phonegap app all responses from my backend API with non 200 status code get converted to 200.

Wondering why this patch hasn't been merged. @c0rrupt Have you signed the CLA as requested? 😄

[c0rrupt]

@ADmad yep, CLA has been signed as requested (all checkboxes are checked in @mary-poppins bot's comment). Core devs mark this PR for 1.2.1 milestone.

[ADmad]

@c0rrupt Okay cool, let's hope it gets merged soon or at least some feedback from the devs.

[philholden]

Spent today trying to find the same problem used the following as a temporary fix:

 status = (protocol == 'file' && status === 0) ? (response ? 200 : 404) : status;

[gauthamses]

+1..

Need fix soon

[IgorMinar]

@c0rrupt unfortunately I'm unable to verify your CLA signature. Can you please sign it again and make sure that you use the same email address as the one associated with your commit in this PR.

[IgorMinar]

this hunk is obsolete

[c0rrupt]

@IgorMinar Has been updated PR, re-signed CLA

[IgorMinar]

@c0rrupt that looks much better! Thanks

[adityamenon]

I'm using 1.2.21, but even now for HTTP 400 requests the .success() callback is being called (I'm using the $http service). Any ideas why?

[caitp]

more than likely it's one of your interceptors returning a value which is not a rejected promise, @adityamenon.

[adityamenon]

Ah, yep, I just began returning $q.reject(response) in my responseError interceptor like in this answer and it works as expected @caitp, thanks! Should I be doing the same thing in my response and request and interceptors as well?

[adityamenon]

Okay, sorry just read the relevant part of the docs that says I can directly modify the objects in case of the request and response properties. I do think it would be nice to mention that returning a promise is compulsory in case of the *Error interceptors. Do you agree?

[caitp]

It's not that it's compulsory, but it's just how promises work --- subsequent chained promises are fulfilled with the result of the promise handler --- if that value is not a rejected promise, then you fulfill the next promise with a value and the subsequent success handler is called.

[adityamenon]

Ah, I get it now. I just wanted to make sure future me or someone else doesn't repeat this mistake, but there is no non-redundant way of warning in that area of the docs... thanks a lot!