Description

When c.JupyterHub.subdomain_host is set, the hubHost variable passed to the frontend (JupyterLab/Notebook) includes the scheme as well (https://myhub.example.org). However, the frontend expects hubHost to be just the hostname (and optional port), without the scheme.

This can cause issues for frontend logic that constructs URLs or interacts with browser APIs requiring just the host.

To Reproduce

1. Set subdomain_host in JupyterHub config:

   c.JupyterHub.subdomain_host = "https://myhub.example.org"

2. Start JupyterHub and launch a single-user server.
3. Inspect the page_config in the frontend (window.jupyterhub or window.page_config_data). Alternatively confirm that JUPYTERHUB_HOST env var contains the URL scheme.
4. Observe that hubHost is:

   "hubHost": "https://myhub.example.org"
   

   instead of the expected:

   "hubHost": "myhub.example.org"
   

Expected behavior

• hubHost should contain just the hostname (and optional port), e.g., myhub.example.org, not include https://.

Actual behavior

• hubHost contains the scheme, e.g., https://myhub.example.org.

Impact

• Frontend code that expects a host (not a full URL) may malfunction, causing URL construction errors, cookie issues, or broken redirects.

Proposed solution

• When constructing hubHost for the frontend, strip the scheme and pass only the netloc/hostname part.

  from urllib.parse import urlparse
  parsed = urlparse(self.hub_auth.hub_host)
  page_config["hubHost"] = parsed.netloc or self.hub_auth.hub_host

Environment

• JupyterHub version: 5.3.0
• JupyterLab or Notebook version: 4.4.6

Additional context

• This issue can lead to subtle frontend bugs that are hard to track down. I found it by backtracking a bug in jupyterlab-collaboration.