Horror with Docker & Reverse Proxy because of all the paths

hey guys, it’s very hard to configure a reverse proxy with docker because nearly every function in papermerge has it’s own path (/upload/, /static/, /nodes/ etc.). It’s even harder if you are running other apps that shares a path with papermerge like /upload/.

My Apache Config looked like:

ProxyPass /papermerge/ http://127.0.0.1:8000/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/

ProxyPass /alltags/ http://127.0.0.1:8000/alltags/ retry=0
ProxyPassReverse /alltags/ http://127.0.0.1:8000/alltags/

ProxyPass /automate/ http://127.0.0.1:8000/automate/ retry=0
ProxyPassReverse /automate/ http://127.0.0.1:8000/automate/

ProxyPass /breadcrumb/ http://127.0.0.1:8000/breadcrumb/ retry=0
ProxyPassReverse /breadcrumb/ http://127.0.0.1:8000/breadcrumb/

ProxyPass /browse/ http://127.0.0.1:8000/browse/ retry=0
ProxyPassReverse /browse/ http://127.0.0.1:8000/browse/

ProxyPass /upload/ http://127.0.0.1:8000/upload/ retry=0
ProxyPassReverse /upload/ http://127.0.0.1:8000/upload/

...

And some functions still doesn’t work. Best solution would be a top-level path like /papermerge/ and then sub-paths for all other functions. This makes Reverse-Proxy configs very easy with 2 lines like this:

ProxyPass /papermerge/ http://127.0.0.1:8000/papermerge/ retry=0
ProxyPassReverse /papermerge/ http://127.0.0.1:8000/papermerge/

I have tested this with many other apps, some of them support Docker Environment Variables to configure this path.

regards

[whysthatso]

i’m curious why you encounter these problems. are you trying to run an apache2 instance infront of the running container setup? or are you trying to replace the apache2 instances inside the docker-compose setup as it’s being run as an application server via mod_wsgi-express? in the latter case i don’t know, in the former case i’m not sure why you would need all these routes?

tbh i don’t know the apache setup, the corresponding nginx vhost for my setup looks like that:

  upstream papermerge_server {
    server app.example.net:42551 fail_timeout=0;
  }

  server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name papermerge.example.net;
    
  <snip ssl stuff>

    client_max_body_size 20M;
    keepalive_timeout 5;
    root /var/www;
    try_files $uri/index.html $uri.html $uri @app;

    location @app {
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_pass http://papermerge_server;
    }

}

[whysthatso]

i understand your use case, of course. just for sake of completeness:

• letsencrypt offers wildcard certificates
• one would probably prefer cname records over a records, but that depends on the underlying infrastructure

and - of course - one avoids a bunch of “horrible” routing issues 😄

but i do acknowledge that there are different scenarios.