-
Notifications
You must be signed in to change notification settings - Fork 332
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
Comments
The fix should we choose to support it sounds as simple as:
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. |
@benjamingr In Deno and Bun, only
And Bun throws this:
Perhaps we should be in line with these and only support |
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 |
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 |
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. |
Yes but if the future 1xx status codes will be supported in service workers, they first have to be supported in |
What is the issue with the Fetch Standard?
Currently we say:
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).
The text was updated successfully, but these errors were encountered: