Prior to this commit relative HTTP requests were not being resolved to absolute even thought the behaviour is documented in https://angular.io/guide/universal#using-absolute-urls-for-http-data-requests-on-the-server.
This caused relative HTTP requests to fail when done on the server because of missing request context. This change is also required to eventually support HTTP requests handled during prerendering (SSG).
Closes#51626
PR Close#52326
`provideClientHydration()` accepts new `HydrationFeature` : `HttpTransferCacheOptions`.
`withHttpTransferCacheOptions` accepts an option object:
* `includeHeaders` : list of headers entries to keep in the cache with the request
* `filter` a callback to determine if a request should be cached
* `includePostRequests`: to include POST requests in the allowed methods
Implements some of the features requested in #50117
PR Close#52029
This commit introduces a new `HttpBackend` implentation which makes requests using the fetch API
This feature is a developer preview and is opt-in.
It is enabled by setting the providers with `provideHttpClient(withFetch())`.
NB: The fetch API is experimental on Node but available without flags from Node 18 onwards.
PR Close#50247
This commit adds support by default for HTTP caching when using `provideClientHydration`. Users can opt-out of this behaviour by using the `withoutHttpTransferCache` feature.
```ts
import {
bootstrapApplication,
provideClientHydration,
withNoHttpTransferCache,
} from '@angular/platform-browser';
// ...
bootstrapApplication(RootCmp, {
providers: [provideClientHydration(withNoHttpTransferCache())]
});
```
PR Close#49699
The deprecated `XhrFactory` export from `@angular/common/http` has been removed.
BREAKING CHANGE:
Deprecated `XhrFactory` export from `@angular/common/http` has been removed. Use `XhrFactory` from `@angular/common` instead.
PR Close#49251
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
This commit introduces new types and symbols related to functional HTTP
interceptors - interceptors which are plain functions with access to DI via
the `inject()` operation.
This new form of interceptor is not exposed publically in this commit, but
the legacy class-based interceptors are refactored to be built on top of the
new API internally.
PR Close#47502
The moved `XhrFactory` still needs to be available from `@angular/common/http`
for some libraries that were built prior to 12.0.0, otherwise they cannot be
used in applications built post-12.0.0.
This commit adds back the re-export of `XhrFactory` and deprecates it.
PR Close#41393
With this change we move `XhrFactory` to the root entrypoint of `@angular/commmon`, this is needed so that we can configure `XhrFactory` DI token at a platform level, and not add a dependency between `@angular/platform-browser` and `@angular/common/http`.
Currently, when using `HttpClientModule` in a child module on the server, `ReferenceError: XMLHttpRequest is not defined` is being thrown because the child module has its own Injector and causes `XhrFactory` provider to be configured to use `BrowserXhr`.
Therefore, we should configure the `XhrFactory` at a platform level similar to other Browser specific providers.
BREAKING CHANGE:
`XhrFactory` has been moved from `@angular/common/http` to `@angular/common`.
**Before**
```ts
import {XhrFactory} from '@angular/common/http';
```
**After**
```ts
import {XhrFactory} from '@angular/common';
```
Closes#41311
PR Close#41313
A long-requested feature for HttpClient is the ability to store and retrieve
custom metadata for requests, especially in interceptors. This commit
implements this functionality via a new context object for requests.
Each outgoing HttpRequest now has an associated "context", an instance of
the HttpContext class. An HttpContext can be provided when making a request,
or if not then an empty context is created for the new request. This context
shares its lifecycle with the entire request, even across operations that
change the identity of the HttpRequest instance such as RxJS retries.
The HttpContext functions as an expando. Users can create typed tokens as instances of HttpContextToken, and
read/write a value for the key from any HttpContext object.
This commit implements the HttpContext functionality. A followup commit will
add angular.io documentation.
PR Close#25751
They aim to improve code readability.
Since they are defined by `const enum` they have zero runtime performance impact
over just using constant literals.
Fixes#23543
PR Close#23548
The `HttpParamsOptions` was not documented or included in the public API even
though it is a constructor argument of `HttpParams` which is a part of the
public API. This commit adds the `HttpParamsOptions` into the exports, thus
making it a part of the public API.
Resolves#20276
PR Close#35829
Fixes#23023.
When a HTTP Interceptor injects HttpClient it causes a DI cycle. This fix is to use Injector to lazily inject HTTP_INTERCEPTORS while setting up the HttpHandler on the server so as to break the cycle.
PR Close#24229
HttpClient is an evolution of the existing Angular HTTP API, which exists
alongside of it in a separate package, @angular/common/http. This structure
ensures that existing codebases can slowly migrate to the new API.
The new API improves significantly on the ergonomics and features of the legacy
API. A partial list of new features includes:
* Typed, synchronous response body access, including support for JSON body types
* JSON is an assumed default and no longer needs to be explicitly parsed
* Interceptors allow middleware logic to be inserted into the pipeline
* Immutable request/response objects
* Progress events for both request upload and response download
* Post-request verification & flush based testing framework
