Errors that occur while reading from the ReadableStream that is returned as part of a `fetch` request were not handled. This change propagates these errors up to the `ClientRequest`.
Previously, there was some logic to use the page host
when possible, but it was problematic still (e.g. #53).
Just use example.com in all cases instead. Since the
request is never sent, this shouldn't cause extra
network traffic (except perhaps a dns lookup).
Fixes#53
This fixes some more edge cases when converting from a Buffer to
an ArrayBuffer.
Additionally, compared v2.0.5, this avoids an unnecessary copy
when sending data in a request body.
Unforunately some browsers use a version of Buffer
that isn't based on a Uint8Array. Add logic to convert
when necessary but not make copies when unnecessary.
When using the fetch api, exceptions thrown inside
ClientRequest._onFinish, which also calls the user callback,
were being caught and turned into 'error' events. This is
not the correct behavior; these exceptions should remain
uncaught to let the browser print them to the console.
From now on, IE8 is only supported if polyfills for `Object.keys`,
`Array.prototype.forEach`, and `Array.prototype.indexOf` are
provided. The suggested polyfills from MDN are provided in
ie8-polyfill.js, or you can use https://github.com/es-shims/es5-shim
for a more complete set of polyfills.
Make options handling logic match node's `http` module more
closely and let the browser handle all of the relative url
cases itself.
This has a few important advantages:
* Behavior is closer to native `http` modula
* Relative paths in urls are handled properly (fixes#16)
* Code is simpler and more obviously correct
Previously, testing for 'ms-stream' and 'moz-chunked-arraybuffer'
support on the xhr object caused warnings to appear in Chrome.
Since fetch will always be used instead of these when available,
short-circuit and return false when fetch is available.
The default behavior now preserves the 'content-type' header, at
the expense of not providing pseudo-streming in Safari, generic
WebKit, and older Chrome. Applications that require streaming
and already use 'prefer-stream' mode will not be affected.
The 'prefer-fast' mode is now deprecated, as that behavior now
matches the default. The 'allow-wrong-content-type' mode is new;
it gives the same behavior as the old default in case binary
streaming is essential.
Fixes#8
In order to have parity with XMLHttpRequest fetch credentials should use same-origin instead of omit
Setting XMLHttpRequest.withCredentials to false has no effect on same-site request
1. This fixes an issue where the `response` module emits an extra
'end'
2. Node doesn't seem to emit 'close', even if "Connection: close"
is specified
3. There isn't a real socket, and this module already doesn't
emit the other socket-related events (and this is documented)
John Hiesey
Feross Aboukhadijeh
John Hiesey
Roman Lisagor
Dominic Tarr
Mikeal Rogers
Xiaoning Liu
ecoslado
Connor Peet
Alex J Burke
Phil Larson
Karissa McKelvey
Matt Crute
Cesar Andreu