When creating a new Headers object using an existing Headers object
the existing Headers map is copied by reference. Therefore adding a
new Header value to the new Headers object also added this value to
the existing Headers object which is not in accordance with the
spec.
This commit alters the constructor to create a deep copy of existing
Headers maps and therefore unlink existing Headers from new Headers.
Closes#6845
BREAKING CHANGE:
any code which relies on the fact that a newly
created Headers object is referencing an existing Headers map is
now broken, but that should normally not be the case since this
behavior is not documented and not in accordance with the spec.
Some test cases incorrectly rely on the side effect of other test cases
importing `NgMatchers`. This commit fixes this by making `expect` in
`core/testing_internal` properly typed.
This remove a breaking change introduced with commit #e7a8e2757b06d572f614f53b648d2fd75df370d2 where json objects passed to requests were not converted into string.
BREAKING CHANGE:
The behavior in this commit is the same as before PR 7260 : the objects sent with the request are converted to a string, therefore there is no need for the user to take care of the serialization.
Fixes#10073
This implements a new class, QueryEncoder, that provides
methods for encoding keys and values of query parameter.
The encoder encodes with encodeURIComponent, and then
decodes a whitelist of allowed characters back to their
unencoded form.
BREAKING CHANGE:
The changes to Http's URLSearchParams serialization now
prevent encoding of these characters inside query parameters
which were previously converted to percent-encoded values:
@ : $ , ; + ; ? /
The default encoding behavior can be overridden by extending
QueryEncoder, as documented in the URLSearchParams service.
Fixes#9348
Fix a bug due to which setting a custom Content-Type header in the
Request led to multiple Content-Types being set on the sent
XMLHttpRequest: first the detected content type based on the request
body, followed by the custom set content type.
Fix#9130.
Automatically recognize XSRF protection cookies, and set a corresponding XSRF
header. Allows applications to configure the cookie names, or if needed,
completely override the XSRF request configuration by binding their own
XSRFHandler implementation.
Part of #8511.
Taken into account the withCredentials property within the request options:
- added corresponding property in the RequestOptions class
- added corresponding property in the Request class
- handle this property when merging options
- set the withCredentials property on the XHR object when specified
Added a test in the xhr_backend_spec.ts to check that the property is actually
set on the XHR object
Closes https://github.com/angular/http/issues/65Closes#7281Closes#7281
Implement the ability to provide objects as request body. The following use cases
are supported:
* raw objects: a JSON payload is created and the content type set to `application/json`
* text: the text is used as it is and no content type header is automatically added
* URLSearchParams: a form payload is created and the content type set to `application/x-www-form-urlencoded`
* FormData: the object is used as it is and no content type header is automatically added
* Blob: the object is used as it is and the content type set with the value of its `type` property if any
* ArrayBuffer: the object is used as it is and no content type header is automatically added
Closes https://github.com/angular/http/issues/69Closes#7310
Florian Knop
Igor Minar
Marcus Krahl
Chuck Jazdzewski
Daniel Leib
Damien Cassan
Jason Choi
Cody-Nicholson
Zhicheng Wang
Marc Laval
Jason Choi
Josh Gerdes
Victor Berchet
Damien Cassan
Jeff Cross
ScottSWu
Dmitry Zamula
Vivek Ghaisas
Alex Eagle
Martin Probst
ScottSWu
Utsav Shah
Thierry Templier
Aliaksei Palkanau
Igor Minar