Allow `new Response` with 101 status code

[benjamingr]

What is the issue with the Fetch Standard?

Currently we say:

If init["status"] is not in the range 200 to 599, inclusive, then throw a RangeError.

A request was recently made to Node.js to support status 101 when initializing requests, i.e. new Response(null, { status: 101 }).

This is because people use Response in server runtimes to indicate well... a response 😅

On the service worker front, I'm not sure how this would be useful outside of testing (but it'd be useful there).

[benjamingr]

The fix should we choose to support it sounds as simple as:

If init["[status](https://fetch.spec.whatwg.org/#dom-responseinit-status)"] is not in the range 100 to 599, inclusive, then [throw](https://webidl.spec.whatwg.org/#dfn-throw) a [RangeError](https://webidl.spec.whatwg.org/#exceptiondef-rangeerror).

Although we would need to carefully go over all the places this might impact and confirm it. Additionally if/when service workers ever support intercepting and caching websocket messages this would also be useful for that.

[ayonli]

@benjamingr In Deno and Bun, only 101 are supported outside the range of 200 - 599. For example, when trying to set the status code to 100, Deno throws this:

Uncaught RangeError: The status provided (100) is not equal to 101 and outside the range [200, 599].

And Bun throws this:

RangeError: The status provided (100) must be 101 or in the range of [200, 599]

Perhaps we should be in line with these and only support 101.

[annevk]

I wonder if this should be a separate concept as it represents an intermediate response. We haven't really figured out how we want to expose these to fetch() consumers as of yet which makes me worry about standardizing them before we decide how to do that.

[benjamingr]

Supporting only 101 should be fine but I’d rather we don’t violate the spec like Bun and Deno..

@annevk I mostly agree but given the efforts involved I doubt an entirely new interface would be coherent especially since Response is already used in service workers.

[annevk]

It is used in service workers, but service workers also lets you pass only one of them, right? If you want to support 1xx properly in service workers, you need to do quite a bit more work I would think.

[benjamingr]

Yes but if the future 1xx status codes will be supported in service workers, they first have to be supported in Response :)