Introduce RequestInit.duplex

[yutakahirano]

Introduce the member, and throw if init.duplex is not set in the
Request constructor, as discussed at #1438.

• At least two implementers are interested (and none opposed):
  • Chrome
  • Mozilla
  • Deno
• Tests are written and can be reviewed and commented upon at:
  • Add tests for RequestInit.duplex web-platform-tests/wpt#34496
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1337696
  • Firefox: This is a part of the streaming upload feature.
  • Safari: This is a part of the streaming upload feature.
  • Deno (not for CORS changes): This is a part of the streaming upload feature.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[lucacasonato]

We need to add a Request#duplex attribute too, otherwise the new Response(resp.body, resp); pattern breaks.

[yutakahirano]

We need to add a Request#duplex attribute too, otherwise the new Response(resp.body, resp); pattern breaks.

I don't understand, this change is solely for requests, not responses.

[lucacasonato]

Sorry, I meant new Request(req.url, req);

[lucacasonato]

Thinking about that more, the pattern is currently unusable in runtimes that don't support stream request bodies. That means this would be a Deno specific issue (which will be addressed by us defaulting RequestInit#duplex to "full" for requests with body: ReadableStream for now).

Exposing Request#duplex would make this pattern work on the client too, like it already does for responses, so I think we should add it regardless.

[yutakahirano]

As you see in the change, currently duplex = 'full' is unconditionally rejected in the constructor. I expect you to fix that in #1254. I expect you to define Request.duplex altogether.

Does this make sense?

[lucacasonato]

I expect you to fix that in #1254.

Yeah, that is my understanding too.

I expect you to define Request.duplex altogether.

I don't quite understand. Are you saying to not introduce the Request.duplex attribute in this PR, and instead do that as part of #1254? I'd rather see Request.duplex added at the same time that RequestInit.duplex is added (so in this PR).

[yutakahirano]

I expect you to define Request.duplex altogether.

I don't quite understand. Are you saying to not introduce the Request.duplex attribute in this PR, and instead do that as part of #1254?

Right, because I don't see a reason to specify it now, and I see a reason not to specify it now.

Specifically,

1. Until Fetch body streams are not full duplex #1254 is resolved, web developers cannot use Request.duplex effectively, as it always returns 'half'.
2. If we fail to specify Fetch body streams are not full duplex #1254, it will be difficult to remove the member without compatibility problems.

This is different from the situation for RequestInit.duplex.

1. RequestInit.duplex forces web developers to specify the member (when the body is a stream), and that will allow us not to specify the default value for now.
2. We can remove RequestInit.duplex if we fail to specify Fetch body streams are not full duplex #1254. There will not be any compatibility problems.

[yutakahirano]

Sorry, I meant new Request(req.url, req);

You can use new Request(req);

[lucacasonato]

Ok, that makes sense to me.

LGTM

[yutakahirano]

Thank you! @annevk , can you take a look at this change?

[annevk]

Thanks, this looks good to me, but we can simplify it a bit further.

I like that we have a note about specifying "full" though. Let's keep that.

[annevk]

I'll merge this on Friday unless anything new comes up. (I assume we'll have the tests sorted by then and @lucacasonato will have had a chance to look at those as well.)