Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow new Response with 101 status code #1759

Open
benjamingr opened this issue Jun 9, 2024 · 6 comments
Open

Allow new Response with 101 status code #1759

benjamingr opened this issue Jun 9, 2024 · 6 comments

Comments

@benjamingr
Copy link
Member

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
Copy link
Member Author

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
Copy link

ayonli commented Jun 10, 2024

@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
Copy link
Member

annevk commented Jun 10, 2024

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
Copy link
Member Author

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
Copy link
Member

annevk commented Jun 10, 2024

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants