Represent withRequestsMadeViaParent() with an internal delegating backend so the interceptor handler can distinguish delegated clients from independent child configurations.
Include the XSRF interceptor in the root token factory so the automatically provided HttpClient retains the documented default protection without requiring provideHttpClient().
When `HttpClient` is called from within an `effect()` or other reactive
context, any signal reads performed inside HTTP interceptors were
inadvertently tracked by that context. This caused the effect to
re-execute whenever those signals changed, regardless of whether the
signal was semantically related to the HTTP call.
The fix wraps the interceptor chain invocation in `untracked()` so that
signal reads inside interceptors — both functional (`withInterceptors`)
and class-based (`withInterceptorsFromDi`) — are invisible to the
calling reactive context. This matches the precedent set by the resource
API, which also wraps its loader in `untracked()` for the same reason.
Fixes#58682
This commit replaces the `XhrHttpBackend` with the `FetchBackend` as the default implementation of the `HttpBackend`.
This introduces a breaking change a the `FetchBackend` does not support the report progress for uploads.
The previous behavior (`HttpXhrBackend`) can be restored by setting `withXhr()` in the `provideHttpClient()` provider function.
DEPRECATED: `withFetch` is now deprecated, it can be safely removed.
BREAKING CHANGE: Use the `HttpXhrBackend` with `provideHttpClient(withXhr)` if you want to keep supporting upload progress reports.
This commit updates the `HttpClient` internals to use the public
`PendingTasks` API which delays stability until the next
`ApplicationRef.tick` instead of causing the application to become
stable synchronously. This is helpful to resolve unexpected issues where
computations happen as follow-up work to the value coming out of the
response.
fixes https://github.com/angular/angular/issues/59352
PR Close#60656
This commit addresses dependency injection defects when using the `withFetch` API. Formerly, utilizing `withFetch` led to the automatic setting of `HttpBackend` to `FetchBackend`, which proved problematic in certain scenarios. Notably, conflicts arose when integrating `withRequestsMadeViaParent` and manually overriding tokens, as observed in instances like `InMemoryWebApiModule`.
PR Close#55652
`HttpClient` uses the `PendingTasks` service to contribute to
application stability. This was added in v16 to support SSR without
relying on an infinite `setTimeout` with ZoneJS like it did pre-v16.
Prior to version 16, this was also only done on the server and did not
affect clients or unit tests (https://github.com/angular/angular/commit/28c68f709cdc930e12bac51a266e7bf790656034).
Today, `PendingTasks` contribute to `ApplicationRef.isStable` but do not
contribute to the stability of `ComponentFixture`. This divergence in
stability behavior was not intended and we plan to make these two
stability indicators the same again, like they were when it was solely
based on the state of the Zone.
By aligning the two behaviors again, this would include all pending
tasks in the stability of fixtures. After investigation, this seems
likely to be a pretty large breaking change. Tests appear to quite often use
`await fixture.whenStable` when there are unfinished requests that have
not been mocked or flushed.
This change prevents request in `HttpClient` from contributing to
stability through the `PendingTasks` automatically but only when using
`HttpClientTesting`. In this scenario, requests need to be expected and
flushed manually for them to resolve. When the test backend and controllers
aren't used, requests should resolve on their own so `await fixture.whenStable`
shouldn't be particularly affected or problematic.
PR Close#54974
This commit adds a logic to produce a warning in case HttpClient doesn't use fetch during SSR.
It's recommended to use `fetch` for performance and compatibility reasons.
PR Close#52037
This rename reflects what the function actually does. Although the intention
is still not to have two different interceptor mechanisms, that is now
communicated in the docs for the function instead of in its name.
Fixes#47764
PR Close#47901
Ordinarily, providing `HttpClient` (either via `provideHttpClient` or the
`HttpClientModule`) creates an entirely separate HTTP context. Requests made
via that client are not passed through the interceptor chains that are
configured in a parent injector, for this example.
This commit introduces a new option for `provideHttpClient` called
`withRequestsMadeViaParent()`. When this option is passed, requests made in
the child context flow through any injectors, etc. and are then handed off
to the parent context.
This addresses a longstanding issue with interceptors where it's not
possible to extend the set of interceptors in a child context without
repeating all of the interceptors from the parent.
PR Close#47502
This commit introduces a new feature for `provideHttpClient` called
`withInterceptors`. This feature exposes and configures the new concept of
functional interceptors.
Functional interceptors use functions instead of classes to implement an
HTTP interceptor. Such interceptor functions have access to the DI context
from the `EnvironmentInjector` in which they're configured via the
`inject()` function. Otherwise, functional interceptors are identical in
capability to the existing interceptor system.
PR Close#47502
This commit introduces the main components of the `provideHttpClient()`
provider API, designed in the style of `provideRouter()`. Initial features
are defined for including legacy class-based interceptors, JSONP support,
and configuring or disabling the builtin XSRF protection.
This API is an alternative to providing `HttpClient` via the
`HttpClientModule`, and is more tree-shakable and more capable than the
NgModule implementation.
Tests are included to validate the new configuration format as well as the
interoperability of the two styles of providing and configuring
`HttpClient`.
PR Close#47502
Jaime Burgos