That's probably still not enough, because you need to be able to push data out the socket immediately after the actual HTTP response, ideally even in the same TCP frame if possible. So calling response.end() doesn't make sense, and letting that stuff be transparently queued doesn't make sense, because you still have immediate access to the raw socket and could inject websocket data before the HTTP 101 response has been written.
The main thing you need is to wait until all previous pending requests have been fulfilled before emitting the 'upgrade' event. The only major remaining issue is that node assumes that the 'upgrade' handler is going to take over the connection and there's no way for that handler to respond with, say, HTTP 404 and continue using the HTTP/1.1 keep-alive connection for further HTTP requests. Maybe just provide the ServerResponse object to to the 'upgrade' event handler the upgrade event handler would ONLY use it if it decided NOT to follow through with the HTTP Upgrade request? i.e. res.writeHead(101) would be illegal. But your race condition is solved by waiting until all prior http requests have been responded to before emitting the 'upgrade' event. Brian On Thu, Apr 12, 2012 at 3:26 PM, Stéphan Kochen <step...@angrybytes.com>wrote: > On Friday 13 April 2012 at 00:20, Mikeal Rogers wrote: > > So, without getting too deep in to the API proposal, you'd like the > "upgrade" event to be passed an HTTP ServerResponse object? > > Yep. :) > > -- > Stéphan Kochen > Two Screen, Angry Bytes > > >
