Fix for the terminal shutdown issue

[gdlmx]

This PR is aimed to fix the problem of Zombie terminal as reported in issue 5061 of JupyterLab. It adds checking for the parameter of websocket request against existing terminals in order to avoid unexpected creation of terminals. According to the issue report, the xtermjs client tries to recreate the websocket connection after termination of the shell process, which then triggers the creation of another terminal (shell process) on the server.

The issue can also be "fixed" in the upstream project terminado, in which the default behavior of NamedTermManager is to automatically start a new terminal in response to a websocket handshake. However, the fix proposed in this PR is cleaner and more efficient.

[takluyver]

I consider it a nice hidden feature that you can create named terminals just by going to the URL, so it would be a shame to lose it. Do you know if there's an issue open about it on xtermjs? I think it should be technically possible for the server side to close down the connection and indicate to xtermjs that it's deliberately being closed.

[gdlmx]

@takluyver I didn't find a relevant issue on xtermjs. In xtermjs, the onclose handler doesn't check the websocket CloseEvent at all, probably because the property values of this event may be browser specific:

I can get "wasClean == true" if I let the client initiate the close() and the server finish with a close() (which is spec). I get a "true" on chrome but not on firefox if the server initiates the close()

Implementing such a feature in xtermjs will require lots of testing.

[gdlmx]

I consider it a nice hidden feature that you can create named terminals just by going to the URL

I agree if the creation is triggered by a http GET request, not by a websocket handshake. Usually the websocket is managed automatically in the background which the user has no direct control on.

[blink1073]

I agree with this sentiment: starting a terminal should be an HTTP request, not a websocket request.

[blink1073]

Thanks!

[rgbkrk]

What would folks think about a special named path like /terminals/new that would create a new terminal?

[blink1073]

That seems reasonable to be, but only if it redirected you to a new numbered terminal url.

[Zsailer]

Seems reasonable to me too. Maybe add to jupyter_server as well 😉

[kevin-bates]

I feel like I'm missing some context. How is this different than a POST against /api/terminals? Are you talking about bringing your own terminal names (rather than numbers) this way? Could someone elaborate a bit more on this? Thanks.

[blink1073]

This would be a URL you visit in your browser, a GET that gives a 302 to a named terminal URL.