fix($http): resolve cached requests with the proper config when hitting a cached promise

[mfield]

If an $http request is cached but not yet resolved, and a second request is made to the same
URL; be sure to resolve the second request's promise with the second request's config object.

The way I read the current docs on $http, the original behavior is not described, so
this does not introduce any backwards compatibility concerns.

My use case is to communicate between interceptors on either side of the same request using data stashed in the config object. Since the interceptors are initialized once by the injector I don't see a good way to store the data in a closure instead. This behavior seems more consistent anyway, since the non-cached and cached-and-resolved cases both work as expected.

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#6534)

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!

[davidjnelson]

Thanks @mfield for the PR! @IgorMinar I'm not sure the best person to ping for $http, so I was hoping you could take a look, thanks!

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[mary-poppins]

CLA signature verified! Thank you!

Someone from the team will now triage your PR and it will be processed based on the determined priority (doc updates and fixes with tests are prioritized over other changes).

[morganrallen]

I came across this while trying to find out if there was a bug in $http when cache returns a promise (yes).
And while messing around with this patch it appears to half fix my problem. There is still a problem in the situation where the cache doesn't have the desired data. In this case the promise should be rejected and the http request should continue. That makes sense, right? I have a patch if so, or I totally missed something on how the cache uses promises.

[pkozlowski-opensource]

@mfield thnx for your PR but we are going to merge #9030 instead as it works corectly with headers and merges cleanly. Please do send us other PRs though.