HttpClient/HttpRequest should support fetch API-specific redirect control

🚀 feature request

Relevant Package

This feature request is for @angular/common/http

Description

#27689 requests a Fetch-based backend for HttpClient. The only response thus far has been “feel free to implement it yourself”. I don’t actually care what backend is used. I’m trying to replace my (fetch-based) back-end interactions with HttpClient so that I can use injected mocks for testing. The problem is that I currently use several features that are not available in the existing API, like the cache and redirect options in the Request and the redirected property of Response.

Describe the solution you’d like

I’d like to see first-class Angluar support for fetch-specific features.

Describe alternatives you’ve considered

I’m talking to back-end APIs that I have no control over. I’m either going to have to a) stick with fetch and figure out how to test my code on my own, or b) switch to HttpClient and rewrite significant portions of my backend interactions to detect and handle redirects that I could have avoided using a simple {redirect: "error"} via native fetch.

[alxhub]

I’d like to see first-class Angluar support for fetch-specific features.

I would too 😃

When it was in development, HttpClient was initially based on fetch, but ran into some issues around browser support (like IE, as always) and around specific features such as cancellation, progress reports, etc.

I think it’s a good time for us to re-evaluate what a fetch-based HttpBackend might look like. There are still some challenges here (implementing the progress events HttpClient exposes on top of fetch would be tricky, how do you intercept a ReadableStream, etc) but I think it might be doable, even if it’s opt-in for now.

[thw0rted]

I should have guessed legacy support was the culprit. Is there an existing ticket for “Drop IE support, raze it to the foundations, and salt the ashes” or should I open a new one?