-
Notifications
You must be signed in to change notification settings - Fork 10
Description
I think I finally tracked down the port exhaustion issue we are seeing from jupyterhub deployments (jupyterhub/configurable-http-proxy#557).
When a websocket request is proxied to an upstream server that does not accept the websocket connection (i.e. responds with regular HTTP response), the connection does not resolve when the response comes in, leaving sockets open until various timeouts. If this happens a lot, it can lead to port exhaustion.
While the correct behavior does seem obvious to me (i.e. proxy.web
should actually happen if upstream responds with a web request, even after proxy.ws
is invoked), how to accomplish that isn't, since the client res
is not available in ws-incoming
.
But the symptom is clear: proxyReq.on("response", ...)
fires in ws-incoming
and has no handler which should ideally propagate the full response up, but at least should terminate the proxied request to avoid leaking sockets.
I've fixed the socket leak in local testing by adding to ws-incoming
:
proxyReq.on("response", (proxyRes: ProxyResponse) => {
log("websocket response!", proxyRes.statusCode);
socket.destroySoon()
});
but that of course results in socket hang up rather than proper proxying.