e3dio

This error `Upgrade response was not returned from callback` https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L483 happens for a specific case: using `Deno.serve` and `Deno.upgradeWebSocket` and then not returning the same response that was returned by...

> I have no branches and always return this response I do see an issue/bug with the new Deno.serve() and websocket route: if the route throws an error before response...

It's tricky because the connection has been 'upgraded' but the websocket doesn't finish opening server-side until the response is successfully returned https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L206 https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L486 If an error is thrown before response...

I'm wondering if it would be simpler to wait until response is returned from callback before calling [op_http_upgrade_websocket_next](https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L195C25-L195C55) That way the upgrade happens in 1 step at same time, instead...

I see this [goAhead](https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L207C17-L207C24) gets resolved before the response is returned so it does fully open the websocket before response returned. I don't see where this is getting resolved though,...

> But since the WebSocket is open-but-technically-inert until the response is returned `goAhead` is getting called before the response is returned, I don't see where it's called from yet. So...

Ok I think I see mistake in code, this should be `await goAhead.promise` not `await goAhead` https://github.com/denoland/deno/blob/main/ext/http/00_serve.js#L207 https://github.com/denoland/deno/blob/main/ext/web/06_streams.js#L125 So it doesn't actually wait for the `goAhead` promise

So you have mistake in code there that triggered WS open early. But even if you fix that and `await goAhead.promise` now you have half-open websocket, open on client side...

3 years and 1 line of code later, we now have working Websocket headers ;) running this in production ```js const headers = new Headers({ 'Set-Cookie': 'Hello=123' }); const {...

I opened different issue to address specifically Server setting headers for Websocket requests. There is no debate that the Server should be allowed to set headers, but there is still...