Fix default_url redirect with default 'main' handler

[gjenkins8]

The expected behavior of ServerApp.default_url is to redirect to (base_url +) default_url when the base url (/) is requested.

But I think #54 broke this by adding a / handler. Which seems to prevent the redirect handler from working.

To fix, I propose conditionally setting the root url handler based on whether default_url is specified in config.

To reproduce: jupyter server --ServerApp.default_url='/please_redirect_here' --ServerApp.token='' --ServerApp.open_browser=False, and navigate to localhost:8888.

Note: the --ServerApp.open_browser=False option is required, as open_browser emulates the redirect logic here. I'll propose removing this logic in a separate PR.

[jasongrout]

CC @Zsailer

[Zsailer]

Thanks, @gjenkins8. This is a reasonable fix to me.

The MainHandler really is just a dummy handler for headless servers to avoid redirect errors that are caused by hitting a URI with no handler. Server extensions that expose a frontend should replace the default_url and redirect the server to hit their own handlers. You're right that this bug was preventing that redirect from happening.

Merging.

[gjenkins8]

Thanks! @Zsailer

[vidartf]

Server extensions that expose a frontend should replace the default_url and redirect the server to hit their own handlers.

I'm a little confused by what is meant with a "server extension" here. I'm used to it meaning something installed with jupyter serverextension, and I'm struggling to make sense of this statement in light of that.

[rolweber]

@vidartf It means an extension of jupyter_server, which should be a Python class derived from here:
https://github.com/jupyter/jupyter_server/blob/master/jupyter_server/extensions_base.py

[vidartf]

@rolweber Thanks for the link. That seems to be an installer class?

As far as I understand, there are these components:

• Jupyter apps (subclasses of JupyterApp), which can be invoked with jupyter <cmd name>
• Server extension (something installed using an extension installer, AFAICT you linked to the base class of that installer), which will be loaded when the server starts, and might do arbitrary modifications to the app.
• A server app (either ServerApp or a subclass of it), that loads the installed server extensions, and starts the server web app.

If you have multiple server extension, should they all have their own default_url? Or set the parent one? Or is this only for subclasses of the ServerApp?

[Zsailer]

I'm a little confused by what is meant with a "server extension" here. I'm used to it meaning something installed with jupyter serverextension, and I'm struggling to make sense of this statement in light of that.

As far as I understand, there are these components:...

@vidartf we've add a new (4th) compontent for creating extensions in #48 , ExtensionApp (I think @rolweber sent the wrong link).

This was specifically built for frontend applications like JupyterLab, notebook, nteract_on_jupyter, and voila. From the perspective of jupyter_server, these applications become "server extensions", i.e. the server exists separate from these applications and they append extra handlers to the server. Those handlers happen to include a frontend application (see more info in #48).

JupyterLab, notebook, etc. should no longer subclass ServerApp, but instead, subclass the ExtensionApp. That's our goal for the future. Checkout jupyter/notebook#4653 and voila-dashboards/voila#270 for examples.

[Zsailer]

If you have multiple server extension, should they all have their own default_url? Or set the parent one? Or is this only for subclasses of the ServerApp?

Yes, each extension should define their own default_url. The ServerApp's default_url is different than an ExtensionApp's default_url.

Here are two cases that happen now:

• If the server is started with extensions enabled using jupyter server --ServerApp.jpserver_extensions={...}, the user lands on the ServerApp's default_url. Users can switch to an extensions landing page by manually changing the URL to the extension's URLs.
• If a server is started by an extension using jupyter <extension_name>, the ServerApp's default url becomes the extension's default_url. That is—it is assumed you're using that extension as the main frontend application for the server.

The current handler for the ServerApp is just a dummy handler and html template. It only exists to avoid errors when the server is started without a frontend application attached (see #54).

[vidartf]

Thanks for helping me understand the nuances in the terminology!

From the perspective of jupyter_server, these applications become "server extensions", i.e. the server exists separate from these applications and they append extra handlers to the server.

So, these ExtensionApps subclass JupyterApp, and can either:

• Launch a ServerApp and add its own server extension to it
• Add its server extension to another ServerApp (e.g. one launched by another ExtensionApp) via the exposed load_jupyter_server_extension

Am I getting it right? If so:

• An extension app will define its default_url
• The load_jupyter_server_extension method of an extension app will not touch the default_url

Or am I still confused?

[Zsailer]

@vidartf everything you said is exactly right. 😃

Sorry for the total lack of documentation. I'm working on this...