Bug report — Rewriting a WebSocket response throws exception due to unsupported status code 101.

[sassanh]

If I try to instantiate a response based on another response, with status code 101, returned by a DurableObject, I get this error:
Responses may only be constructed with status codes in the range 200 to 599, inclusive.

This is causing an issue in next-on-pages as reported here

I don't know if it should be addressed here, or next-on-pages should put an exception for this case to directly return the response coming from the DurableObject and return it without re-instantiation.

[kentonv]

As a work-around, you can change the status to 200 -- because it has a webSocket property, the system will change it back to 101.

[sassanh]

@kentonv Thanks for the quick response! I will try that, for now I'm using this minor patch on next-on-pages

Do you know if it should be taken care in workerd by allowing status code 101, or by providing an api for handling special cases when response is being forwarded from other services like durable objects, or it should be taken care in next-on-pages and it is not going to be supported to instantiate a response with status code 101 in workerd?

[jasnell]

Supporting 1xx interim responses in workers is something we've discussed but is not trivial as it is something that would need to be implemented deep throughout our stack. I do want to make this happen but we'll need to discuss internally around priority and feasibility. I'm going to change this issue to a feature request as it's not really a bug as much as a limitation of the current design/implementation.

[sassanh]

@jasnell Thanks! That makes sense.

So to wrap it up and avoid misinterpretation of this issue in the future, if I understand it correctly:

1. We are not looking for WebSocket support in workerd here, we just want to be able to pass WebSocket responses coming from durable objects, for example.
2. Currently, workerd can pass WebSocket responses without any workarounds or hacks, with its official API, as long as one doesn't try to modify it in workerd.
3. If one wants to add headers to the WebSocket Response object coming from a durable object, for example, or change its status code to something in the range 1xx, that's not supported in the official API at the moment, but as a workaround, in the case the desired status code is 101 and not any arbitrary number in the range 1xx, they can set the status code to 200, and the system will change it to 101 automatically.

[kentonv]

I've changed the title of this bug to better reflect the specific bug here.

@jasnell the ask is NOT to support 1xx in general. The problem here is that fetch() itself returns a Response with status 101 when the response is a WebSocket response, and attempts to rewrite that response (e.g. change a header) fail because we throw an exception about not supporting 1xx status codes.

This is a bug which we should fix. We should simply say that if the Response is specifically a WebSocket response (its webSocket property is non-null), then we allow it to have status 101.

[jasnell]

This is a bug which we should fix. We should simply say that if the Response is specifically a WebSocket response (its webSocket property is non-null), then we allow it to have status 101.

SGTM

[sassanh]

Thanks!

This might help others with similar issues:

My original challenge was serving the WebSocket endpoint on the same subdomain as my web application, which led me to try proxying responses. Even with a workaround to deal with the issue reported here, I ran into the issue of the connection closing after 100 seconds of inactivity due to hibernation (noted in the docs but a little easy to miss).

Then, I discovered the routes feature, a handy tool that allows serving different workerd instances on different paths without needing to proxy WebSocket responses.