Currently HttpClient sends requests for JSON data with the
XMLHttpRequest.responseType set to 'json'. With this flag, the browser
will attempt to parse the response as JSON, but will return 'null' on
any errors. If the JSON response contains an XSSI-prevention prefix,
this will cause the browser's parsing to fail, which is unrecoverable.
The only compelling reason to use the responseType 'json' is for
performance (especially if the browser offloads JSON parsing to a
separate thread). I'm not aware of any browser which does this currently,
nor of any plans to do so. JSON.parse and responseType 'json' both
end up using the same V8 code path in Chrome to implement the parse.
Thus, this change switches all JSON parsing in HttpClient to use
JSON.parse directly.
Fixes#18396, #18453.
PR Close#18466
Today, constructing a new GET request with headers looks like:
const headers = new HttpHeaders({
'My-Header': 'header value',
});
http.get('/url', {headers}).subscribe(...);
This indirection is unnecessary. It'd be more ergonomic to write:
http.get('/url', {headers: {'My-Header': 'header value'}}).subscribe(...);
This commit allows that new syntax, both for HttpHeaders and HttpParams.
In the HttpParams case it also allows construction of HttpParams with a map.
PR Close#18490
This is needed as the typescript no longer elides type reexports
in the generated code when using transformers.
A nice side effect is that this make summaries shorter and produces
less reexports as we rollup reexports.
PR Close#18788
Previously, we only did this when setting the `generateCodeForLibraries: false`.
This is needed so that libraries compiled with `generateCodeForLibraries: true` can be used as dependencies of other compilation units.
PR Close#18788
Alex Eagle
Pawel Kozlowski
Olivier Combe
Alex Rickabaugh
Victor Berchet
Miško Hevery
David Herges
Tobias Bosch
Austin McDaniel
Yuan Gao