Allow passing a Request instance to Request constructor #179
Conversation
|
Oh awesome! That's was really fast. |
|
I just looked through the spec and comparing it with Chrome Canary they seem to at least behave the same. |
The new Request instance becomes essentially a clone of the old Request. The original Request's body becomes unusable. https://fetch.spec.whatwg.org/#dom-request
This makes the test error more correct when the `then` block raises an assertion error. The `catch` block needs to re-raise the same exception, not swallow it and disguise it like another failure.
mislav
force-pushed
the
request-to-request
branch
from
c8ac353
to
86d8ec5
Compare
|
We got a legitimate failure in Chrome because it doesn't conform to the spec fully: a Request with an already consumed body should throw an exception, and in Chrome it doesn't. @dgraham What do we do in these situations? |
|
@mislav I usually test the behavior in Firefox as well, to determine if both browsers agree on the implementation. It could be a misreading of the specification or a real Chrome bug. |
|
It passes in Firefox, as well as my polyfill implementation based on the spec. It's not a super-important feature, though— it just throws a TypeError early when the body has already been consumed. It looks like Chrome implementation in general allows bodies to be re-consumed. |
|
Possibly related to the following? |
|
Thanks @cesarandreu. @dgraham It's a real Chrome bug due to the spec only formalizing this very recently. Should I skip the test in Chrome? |
|
@mislav That sounds fine. We can re-enable the test after Chrome ships a fix for the bug. |
The fetch spec instructs that Request should throw a TypeError when given a Request with an already consumed body, but Chrome's implementation doesn't respect that yet.
Allow passing a Request instance to Request constructor
I tried to match the spec as closely as possible. This should also make it possible to use
fetch(request, options)invocation.Fixes #177
/cc @dgraham @cesarandreu