Cant´t open Notebook in a directory after activating jupyterlab-collaboration

[guyq1997]

Bug description

After I activate the Jupyter-collaboration extension.
I can normally open a notebook in my home directory (/home/joyvan)
But can not connect to Kernel and open a notebook in a folder (/home/joyvan/[some newfolder]).

Browser says that, he can´t find the file in the directory

The Cause according my guess:
This Problem doesn´t exsit if i only use Jupyterhub internal Proxy (CHP). So I guess the problem is the compatibility of Jupyter-collaboration extension and Apache2?

I found that the single user server and my browser are opening different URL. Single user server found the right url but My Browser doesn´t.

Browser says it can´t open the Note book because following URL doesn´t exist
/user/yuqiang/api/collaboration/session/Assignment%2FVisualisierung_CO2_Konzentration.ipynb 404 (Not Found)

Single user Server says that, it can successfully access to it:
[I 2024-03-28 15:41:38.678 YDocExtension] Processed 53 Y patches in one minute
[I 2024-03-28 15:41:38.678 YDocExtension] Connected Y users: 3
[I 2024-03-28 15:41:40.648 ServerApp] 200 GET /jupyterhub/user/yuqiang/api/contents/Assignment/Visualisierung_CO2_Konzentration.ipynb?type=notebook&content=0 (yuqiang@::ffff:172.31.0.3) 3.34ms

How to reproduce

1. Apache2 as reverse proxy
2. Activate Jupyter-collaboration extention
3. Open a Directory in your workspace
4. Open a notebook

Expected behaviour

Note book can be opened

Actual behaviour

Notebokk can not be opened

Your personal set up

• OS: Ubuntu 22.03

• Version(s): Jupyterhub 4.0.2 Jupyterlab 4.0.7

Full environment

# paste output of `pip freeze` or `conda list` here

Configuration

c.Spawner.cmd = “jupyterhub-singleuser”

c.Spawner.debug = True
c.ConfigurableHTTPProxy.debug = True
c.DockerSpawmer.use_internal_ip = True

c.JupyterHub.spawner_class = DockerSpawner
c.DockerSpawner.image = “guyq1997/jupyterlab-dhbw”
c.JupyterHub.hub_ip = “jupyterhub”
c.JupyterHub.bind_url = ‘http://jupyterhub:8000/jupyterhub’

c.DockerSpawner.network_name = os.environ[“DOCKER_NETWORK_NAME”]
c.DockerSpawner.extra_host_config = { ‘network_mode’: os.environ[“DOCKER_NETWORK_NAME”] }
c.DockerSpawner.start_timeout = 120
c.DockerSpawner.remove = False
c.JupyterHub.authenticator_class = ShibbolethAuthenticator
c.ShibbolethAuthenticator.headers = [“Givenname”]
c.Authenticator.shibboleth_logout_url = “https://example.org/Shibboleth.sso/Logout”

Apache:

#Listen 80
<VirtualHost *:80>
  ServerName**
  Redirect / https://**/
</VirtualHost>
 
#Listen 443
<VirtualHost *:443>
  ServerName **
 
  ServerSignature Off
  SSLProxyEngine on
  # Enable HTTP/2, if available
  Protocols h2 http/1.1
 
  # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
  Header always set Strict-Transport-Security "max-age=63072000"
 
  # Configure SSL
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/**/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/**/privkey.pem
  SSLOpenSSLConfCmd DHParameters /etc/ssl/certs/dhparams.pem
  # Intermediate configuration from SSL-config.mozilla.org (2022-03-03)
  # Please note, that this configuration might be outdated - please update it accordingly using https://ssl-config.mozilla.>  SSLProtocol TLSv1.2
  SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA>  SSLHonorCipherOrder     on
  SSLSessionTickets       Off
  SSLCompression          Off
 
#----------------------Shibboleth-------------------------------
  UseCanonicalName On
  Include /etc/shibboleth-ds/shibboleth-ds.conf
  Redirect seeother /shibboleth https://**/Shibboleth.sso/Metada>  RedirectMatch /start-session$ /Shibboleth.sso/Login
 
  <Location /Shibboleth.sso>
    AuthType None
    Require all granted
  </Location>
 
  <Location /shibboleth-sp>
    AuthType None
    Require all granted
  </Location>
 
  Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css
#----------------------Jupyterhub-------------------------------
  RewriteEngine On
 
  RewriteCond %{HTTP:Connection} Upgrade [NC]
  RewriteCond %{HTTP:Upgrade} websocket [NC]
  RewriteRule /jupyterhub/(.*) ws://jupyterhub:8000/jupyterhub/$1 [P,L]
  RewriteRule /jupyterhub/(.*) http://jupyterhub:8000/jupyterhub/$1 [P,L]
 
  <Location /jupyterhub>
 
    RequestHeader unset Accept-Encoding
#    ProxyPass         http://jupyterhub:8000/jupyterhub
#    ProxyPassReverse  http://jupyterhub:8000/jupyterhub
 
    RewriteEngine On
    ProxyPreserveHost on
 
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    Require valid-user
    ShibUseHeaders On
    RequestHeader set X-Remote-User %{REMOTE_USER}s
    ProxyPass        http://jupyterhub:8000/jupyterhub
    ProxyPassReverse http://jupyterhub:8000/jupyterhub
  </Location>
</VirtualHost>

Logs

[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! 🎉

[guyq1997]

I found the problematic Request is sent by Apache Webserver. The Request sent by Apche seems to be blocked. Other Requests, which are sent by tornado, are no problem.

Any suggestions to let tornado send the request instead of Apache?

[jammann]

I'm experiencing the same issue, as discussed here https://discourse.jupyter.org/t/strange-issue-with-rtc-in-jupyterhub-behind-apache-http-reverse-proxy/27288

I'm testing with JupyterHub 5.0.0 and JuypterLab 4.2.4

Will give the Beta 3.0.0 a try if that changes anything

[jammann]

The issue persists also with 3.0.0b1

[krassowski]

Could it be that your proxy is not letting requests with PUT method through?

[jammann]

Luckily, @guyq1997 pointed me to the correct solution, which was in his thread here https://discourse.jupyter.org/t/cant-connect-to-kernel/24705/1

Adding

AllowEncodedSlashes On

to my Apache config solved the issue :-)

[jammann]

Thanks @krassowski for your help. The proxy does pass the PUT requests, but mangles them (without AllowEncodedSlashes) beyond recognition for the Jupyter collaboration backend.

If @guyq1997 agrees, I guess this issue could be closed. His solution works like a charm for me, also.