[whatwg/fetch] non-null body with GET/HEAD requests (Issue #1705)

@annevk @domenic ... I know that this has been discussed previously but I'd like to re-open the conversation about what happens when someone creates a `Request` object with a non-`null` `body` when `method` is equal to `GET` or `HEAD`. I am specifically referring to bullet point 35 at https://fetch.spec.whatwg.org/#dom-request

![image](https://github.com/whatwg/fetch/assets/439929/f75c5950-52df-4128-942b-34a098be6ecc)

While the HTTP spec defines `GET` and `HEAD` such that request body payloads are meaningless, it does not forbid them, and there are production API in the wild (looking at you Elastic) that will allow specifying a body payload with a `GET`. Such APIs are currently not usable with `fetch` because of the restriction in the spec that requires that an error be thrown with non-null bodies.

This causes direct problems for us in the Workers runtime because we have cases where customers want to do something like...

```
const newRequest = new Request(request.url, { method: request.method, body: request.body });
```

Without having to introduce special case logic for when `request.method` happens to be `GET` or `HEAD`. In the implementation of `Request` on the server-side, we will allow receiving a `GET` with a `content-length: 0` header that will result in the `request.body` being a zero-length stream rather than `null`.

The change in the spec that I would like to see is relaxing the requirement on bullet point 35 of https://fetch.spec.whatwg.org/#dom-request to say that a non-null `body` is always accepted by the `Request` constructor but that host implementations are free to ignore the `body` if the method used is known not to apply any semantics to the body payload. This would allow browser implementations to continue just ignoring the body payload for `GET` and `HEAD` but would allow other implementations to *choose* how to handle those.

As far as I can tell, such a relaxation would not be breaking for the web in any way, and would afford runtimes greater flexibility to choose how such methods are handled.

Specifically, the change would be that the following would no longer throw an error and implementations would be free to decide whether or not to consume the `body` based on it's understanding of the semantics of whatever `method` is used.

```
new Request('https://example.com', { body: new ReadableStream() });
new Request('https://example.com', { body: new Uint8Array(n));  // where n is any value
```


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

Message ID: <whatwg/fetch/issues/1705@github.com>