Improving usage/detection of URL prefix in deployed environments

[banesullivan]

TL;DR

Is there a better way to use jupyter-server-proxy / know the proxy URL in deployed environments such as MyBinder, JupyterHub, and SageMaker?

Users on a handful of projects where I leverage jupyter-server-proxy struggle to get the correct URL prefix in managed deployed environments; often it's just '/{JUPYTERHUB_SERVICE_PREFIX}/proxy/<port> but other times it can be more nuanced.

Are there any options or existing efforts to alleviate this pain point for users?

Use case

I've been leveraging jupyter-server-proxy on a handful of projects in a similar fashion, which, may be different from the use cases jupyter-server-proxy is designed for. I'd appreciate clarification on if this usage scenario is well-supported and if there are ways to improve my usage of jupyter-server-proxy for these use cases to relieve configuration pain for our users.

In each of these projects, we spin up one or many web servers within the Python kernel (at runtime) to then access from the client-side Jupyter notebook. Two examples:

1. Serving tiles for large images to visualize interactively on a map. The user launches a tile server (with their configurations defined at runtime) for a given "image" instance in their kernel. We then combine Jupyter widgets like ipyleaflet with the REST tile endpoint we've launched on an arbitrary port on the host machine. We need the client browser to access that server to fetch the tiles. See Add ipyleaflet representation girder/large_image#1065 and https://github.com/banesullivan/localtileserver

3. Custom Jupyter "widgets" as an iFrame. In PyVista, we serve a single web application that links to individual 3D plots the user creates in their kernel. We need full access to the port this application runs on and display the application as an iFrame in the Jupyter Notebook so to the user it's just like any other widget. This web app must be launched within the same thread as the user's Python kernel's main thread. More details here and here

The primary constraint shared in these use cases is that the web server must be a part of the user's Python kernel process: we cannot launch the server ahead of time, and we cannot share servers across Python sessions (notebooks).

Using jupyter-server-proxy has gone excellently for these use cases with only minor issues around end-user configuration and request timeouts -- which is what I hope to optimize and solicit as improved support for in jupyter-server-proxy.

Help!

1. Are these use cases well-supported by jupyter-server-proxy? I'm asking because the documentation focuses on launching a single standalone web application on the Jupyter Server rather than this launching of arbitrary servers from within a user's Python session.

2. Are there any ways to improve knowing the URL prefix ahead of time in deployed environments (like MyBinder or SageMaker) to prevent users from having to debug different prefixes in /<prefix>/proxy/<port> for these use cases?

Common prefix scenarios

• MyBinder: f"{os.environ['JUPYTERHUB_SERVICE_PREFIX']}/proxy/{{port}}"
• SageMaker: f"studiolab/default/jupyter/proxy/{{port}}"
• Colab: actually, jupyter-server-proxy isn't needed for these use cases as localhost is remapped by Colab (reference)

Related

Pinging a few folks who may want to follow this issue: - @giswqs, @akaszynski

• Setting Jupyter backend to Trame hangs and displays blank widget pyvista/pyvista#3987
• Displaying images on remote JupyterHub banesullivan/localtileserver#134
• Support for Amazon SageMaker Studio Lab banesullivan/localtileserver#128
• again a poor soul not managing to serve the tiles on remote server  banesullivan/localtileserver#95
• Cannot view tiles in remote Jupyter environment banesullivan/localtileserver#66

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[giswqs]

It would be nice to have a solution that works across platforms, such as MyBinder, Google Colab, JupyterHub, Amazon SageMaker, Microsoft Planetary Computer.

[manics]

JUPYTERHUB_SERVICE_PREFIX is the standard way to get the base prefix with JupyterHub. As far as I know SageMaker and Colab aren't open-source, so I don't think there's much we can do. However if there's a "well known" standard way to get the prefix we could consider supporting it. Are you aware of any documention?

If not, it might be better to move this discussion to the Jupyter Community Forum https://discourse.jupyter.org/ where people from across the Jupyter ecosystem hang out, since they may have run into this issue with other extensions.

[ryanlovett]

Are these use cases well-supported by jupyter-server-proxy? I'm asking because the documentation focuses on launching a single standalone web application on the Jupyter Server rather than this launching of arbitrary servers from within a user's Python session.

Perhaps it is not well-supported right now, because that hasn't been the focus, but that doesn't mean it couldn't be. I'll add some initial thoughts below, but as @manics said it might be worthwhile to discuss on discourse.

Are there any ways to improve knowing the URL prefix ahead of time in deployed environments (like MyBinder or SageMaker) to prevent users from having to debug different prefixes in //proxy/ for these use cases?

The only way to know the path_info of the managed process (the part after the path to the user's server) in advance is with a named server proxy like those for RStudio, VSCode, noVNC, etc., although these are for single instances. These are made available via entry points where the configuration is known in advance. Right now all existing entry points are loaded when the extension is loaded.

I imagine that there could be a jupyter-server-proxy HTTP API to either create new named services, or to reload any new entry points that have been created since the extension was loaded. This would enable the user to run some code to start a proxied service with an endpoint of their choosing.

[banesullivan]

@manics and @ryanlovett, thank you both for this initial feedback! I'll try to re-pose some of this discussion on Discourse.

I imagine that there could be a jupyter-server-proxy HTTP API to either create new named services, or to reload any new entry points that have been created since the extension was loaded. This would enable the user to run some code to start a proxied service with an endpoint of their choosing.

This is a neat idea. I suppose I am confused about why something must be a new named service to know the path_info... is this not available for the main /proxy/<port> service?

[manics]

The path info (X-Forwarded-Context and X-Proxycontextpath) is already passed, see the tests:

jupyter-server-proxy/tests/test_proxies.py

Lines 205 to 224 in 98f8f0c

	def test_server_proxy_port_non_absolute(
	a_server_port_and_token: Tuple[int, str]
	) -> None:
	PORT, TOKEN = a_server_port_and_token
	r = request_get(PORT, "/proxy/54321/jkl", TOKEN)
	assert r.code == 200
	s = r.read().decode("ascii")
	assert s.startswith("GET /jkl?token=")
	assert "X-Forwarded-Context: /proxy/54321\n" in s
	assert "X-Proxycontextpath: /proxy/54321\n" in s
	def test_server_proxy_port_absolute(a_server_port_and_token: Tuple[int, str]) -> None:
	PORT, TOKEN = a_server_port_and_token
	r = request_get(PORT, "/proxy/absolute/54321/nmo", TOKEN)
	assert r.code == 200
	s = r.read().decode("ascii")
	assert s.startswith("GET /proxy/absolute/54321/nmo?token=")
	assert "X-Forwarded-Context" not in s
	assert "X-Proxycontextpath" not in s