[whatwg/fetch] Feature detecting request stream bodies (#1275)

I'm trying to figure out a way to feature-detect request streaming without requiring a network connection.

Unfortunately Safari complicates this, as it supports creating `Request` objects with stream bodies, but it doesn't support using them with `fetch()`.

However, I've come up with the following:

```js
const supportsRequestStreams = (async () => {
  const supportsStreamsInRequestObjects = !new Request('', {
    body: new ReadableStream(),
    method: 'POST',
  }).headers.has('Content-Type');

  if (!supportsStreamsInRequestObjects) return false;

  return fetch('data:a/a;charset=utf-8,', {
    method: 'POST',
    body: new ReadableStream(),
  }).then(() => true, () => false);
})();
```

Browsers that don't support streams in request objects would interpret the `ReadableStream` as a string, and therefore set the `Content-Type` to `text/plain;charset=UTF-8`, so that's an early exit.

Otherwise, it performs a fetch to a data url using a stream body. This depends on a few things:

- `POST`ing to a data-url is fine, even if the body is a stream. The spec support this, and browsers seem to allow it.
- Browsers that support streams in request objects, but _don't_ support fetching them, will reject even if the body isn't used (it isn't used when POSTing to a data url). There's nothing in the spec to handle this currently.
- Browsers don't try to consume the stream (it never closes). Although, I guess I could just close it.

Proposal:

- Add a step to https://fetch.spec.whatwg.org/#fetch-method to cater for the current Safari behaviour where it rejects requests with streaming bodies. Maybe add a note to suggest that UAs shouldn't create this mismatch in future?
- Add wpts to cover the feature detect above.

WDYT?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1275