Response.body is not null for fetch responses with null status codes or HEAD methods

• Component: Page Loading
• Status: NEW ---

[Luca Casonato]

The fetch spec mandates that `Response.body` should be `null` if the `Response` has a null status code (like 204), or if the `Response` is the result of a request with a `HEAD` method.

WebKit correctly enforces this for manual construction of `Response` using the response constructor (ie `new Response("hey", { status: 204 })` errors), but it does not for responses originating from the network:

```js
const resp = await fetch("https://example.com", { method: "HEAD" });
console.log(resp.body); // this is not null
```

WPTs for this were added here: https://github.com/web-platform-tests/wpt/pull/32813

[Alexey Proskuryakov]

Curious what the point of this spec mandate is. Seems like Fetch should reflect what the server sent, not its opinions on what it should have sent.

[Anne van Kesteren]

I think for some of these, e.g., `HEAD` there's no way to include a body, but there might not be a general way to exclude a body? At least not in HTTP/1. 

And the specification mandates browser behavior as far as I know. I think even if the server included a response body for a 204 response, the browser would drop it. The question is whether that results in the empty byte sequence as body, or lack of body.

In browsers the API can return null in a number of cases, but not when it's a server-generated response as you say. I would be somewhat okay with standardizing upon that behavior. It shouldn't be too hard to change null to the empty byte sequence in a couple of places. Still unfortunate that we didn't define a Response to always have a body from the onset, but it might be too late for that now?

[Luca Casonato]

I would not be in favor of standardizing the current behavior unless we also allow `new Response(new ReadableStream({}), {status: 204})`. Otherwise the following does not work:

```js
const resp = await fetch("https://page-that-returns-204");
const resp2 = new Response(resp.body, resp); // resp.body is an empty ReadableStream right now
```

That is a relatively common pattern I have seen in the wild for Deno users.

I don't see why we couldn't standardize that `new Response(null, { status: 204 })` shouldn't create a `Response` with a 0 length `ReadableStream` as `.body`. If we do that though, we should also allow any body for null body status codes, and not limit it to `null` like we do now. I don't expect that anyone relies on either of these behaviors.

[Radar WebKit Bug Importer]

<rdar://problem/89226388>