By default, the `FetchBackend` on SSR will limit the response body size to 10 MB.
If the response body exceeds this limit, an error will be thrown.
This default value can be configured by providing by setting the `maxResponseBodySize` in `provideServerRendering`.
This is to prevent DoS on the server when loading large files
(cherry picked from commit 2acca1165d)
In order to raise an error on upload progress on the `FetchBackend`, we split `reportProgress` into 2 respective properties.
DEPRECATED: The `reportProgress` option is deprecated please use `reportUploadProgress` & `reportDownloadProgress` instead.
Allows throwing from the resource's params function to transition the
resource to a status other than resolved.
In particular, the following values can be thrown from params:
- `ResourceParamsStatus.IDLE` causes the resource to become `idle`
(equivalent to returning `undefined`)
- `ResourceParamsStatus.LOADING` causes the resource to become `loading`
- Any `Error` object causes the resource to become `error` and report
the error that was thrown via `.error()`
To simplify chaining together resources, this PR also introduces a
context object passed into to the `params` functon. This context
contains a `chain` function that can be used to get the value of a
resource that the params want to depend on, while automatically
propagating the idle, loading, and erorr states of the resource forward.
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 sets up the necessary changes that would allow us to safely migrate G3 before switch to the `FetchBackend` by default.
For now the `HttpXhrBackend` is still the default backend for the `HttpClient`.
Adds support for the `referrerPolicy` option in `HttpResource`, allowing developers to control how much referrer information is sent with each HTTP request.
PR Close#64283
Introduces a referrer policy option for HTTP requests to allow specifying the referrer information sent, improving privacy and security controls.
PR Close#64116
Since HTTP/2, responses no longer contain a status text besides the status code, which caused our default value of 'OK' to be used in HttpErrorResponse.message.
DEPRECATED: `HttpResponseBase.statusText` is deprecated
PR Close#64176
This commit changes `Resource.hasValue()` and its derived types to improve narrowing
of resources whose generic type either does not include `undefined` (i.e. when a default
value has been provided) or when the generic type is `unknown`. This fixes the undesirable
behavior where `hasValue()` would cause the `else` branch of an `hasValue()` conditional
to have a narrowed type of `never`, given that the `hasValue()`'s type guard covers the
entire type range already (meaning that the type in the else-branch cannot be inhabited
in the type system, yielding the `never` type).
By making the `hasValue()` method only a type guard when the generic type includes `undefined`
these problems are avoided.
Fixes#60766Fixes#63545Fixes#63982
PR Close#63994
Add support for the Fetch API's responseType property in HttpResponse and HttpErrorResponse when using HttpClient with the withFetch provider.
PR Close#63043
Add support for the Fetch API's redirected property in HttpResponse and HttpErrorResponse when using HttpClient with the withFetch provider.
The redirected property indicates whether the response was the result of an HTTP redirect, providing valuable information for security, debugging, and conditional logic.
PR Close#62675
The `timeout` option is implemented in the different HTTP backends, but the option is not actually passed to the backends. `transferCache` is also missing in one signature. This commit adds both options to `HttpClient`.
Fixes#62581
PR Close#62586
Add support for mode and redirect options in Angular's HttpClient based on fech provider to enable control CORS behavior and redirect handling
PR Close#62315
This commit adds support for the Fetch API's keepalive option when using HttpClient with the withFetch provider.
The change includes:
- Added keepalive to HttpRequestInit interface
- Modified FetchBackend to pass the option
- Added some unit test
PR Close#60621
The non reactive usage ``httpResource(\`http://test/${myId()}\`` gave the false impression that it was reactive when the signal was invoked. We prevent any possibility of oversight by removing the non reactive signature.
PR Close#60537
This commit updates golden files that got changed after swtiching to relative paths. There are no actual change to the APIs, the golden file updates capture the change in imports.
PR Close#60623
Instead of relying on Microsoft's API extractor for `d.ts` bundling,
we are switching to Rollup-based `.d.ts` bundling.
This allows us to support code spliting, even for `.d.ts` files,
allowing for relative imports to be used between entry-points, without
ending up duplicating `.d.ts` definitions in two files. This would otherwise cause
problems with assignability of types.
It also nicely integrates into our existing rollup configuration, and
overall simplifies the `ng_package` rule even further!
Notably `tsup` also uses this rollup plugin, and it seems to work well.
Keep in mind that Microsoft's API extractor is pretty hard to integrate,
caused many problems in the past, and isn't capable of code splitting.
This aligns our d.ts bundling with the .mjs bundling (great alignment).
PR Close#60321
`HttpClient` has a lot of overloads to achieve proper type checking, however each overload is also very long which makes it hard to read on adev. These changes replace the object literal types with `Record` to make them a bit more concise.
PR Close#59901
`httpResource` is a new frontend to the `HttpClient` infrastructure. It
declares a dependency on an HTTP endpoint. The request to be made can be
reactive, updating in response to signals for the URL, method, or otherwise.
The response is returned as an instance of `HttpResource`, a
`WritableResource` with some additional signals which represent parts of the
HTTP response metadata (status, headers, etc).
PR Close#59876
SkyZeroZx