We discussed this at the Jupyter Server meeting today: jupyter-server/team-compass#4 (comment)

@bollwyvl I would like to address this one in jupyter server directly. But I have a doubt on the best way to achieve this.

Should this feature be implemented like a middleware filtering at runtime the request or at the handler registration? In the latter case, this means monkey patching the handler class if some verbs need to be blocked (like get is allowed but not post), isn't it?

As the definition of an handler selector could be either a string or a Matcher object, the best generic approach leans towards a middleware approach.

I think the goal of this not to get into some kind of monkeypatch-off for the illusion of security, but rather to have a declarative way to impact how the server works at a deep level when one controls the environment.

As for the low-code part: maybe the best way would be leveraging an existing specification (OpenAPI)... or in the case of the whole jupyter architecture, two specifications, as we would need OpenAsync to describe kernel websockets.

The closest thing I've seen in the wild is connexion, but it's a bit heavy, but the idea is sound: hand-written specs not used for anything get stale and auto-generated ones need the system to actually be running, so really aren't a very good contract. If, instead, the spec was the definition of the system, and it could not even respond to things not available there, then it would be much clearer.

Perhaps JSON Patch of a spec could do the thing. So add_handler becomes register_module and patch_spec, and each individual extension to the system augments the master document. Once all the components have provided their patches, then the user/owner can apply their patches: they'd lack the ability to add any new implementations via moduleId, but could stop different routes.

monkey patching the handler class

In the past, I had done it within tornado after the match, but before HTTP method invocation in RequestHandler.prepare.

Run-time filtering in the matching process per-request would be even better, as the handler might do stuff in its constructor we don't want.

Thanks Nick for the information and pointers.

I am not sure I fully understand the issue here. It seems to me that one could manually pick the handlers they need? For example in voila-dashboards/voila#846, we don't need to use jupyterlab_server's add_handlers, we could probably manually add the labextensions handler, the theme handler and the mathjax one?