Running Seafile and Seahub behind Caddy proxy

[patrik (Patrik Arvidsson)]

I’m trying to move over from nginx proxy to caddy, and seafile is running fine but they are requiring a separate proxy for /seafhttp to allow uploads through the web interface. Below is a working excerpt from my nginx config.

location / {
    proxy_pass http://10.0.1.29:8000;
    sub_filter_once off;
}
location /seafhttp {
    rewrite ^/seafhttp(.*)$ $1 break;
    proxy_pass http://10.0.1.29:8082;
    client_max_body_size 0;
    proxy_connect_timeout  36000s;
    proxy_read_timeout  36000s;
    proxy_send_timeout  36000s;
    send_timeout  36000s;
}

I’m very new to this and the above config (as with my other proxies) is a result of trial and error. I’m guessing it’s the rewrite line that gets this to work but I don’t have the knowledge to write the same in Caddy. Below is my Caddyfile.

xx.xxxxxx.xx {
    proxy / 10.0.1.29:8000 {
        proxy_header Host {host}
        proxy_header X-Forwarded-Proto {scheme}
    }
    proxy /seafhttp 10.0.1.29:8082
    rewrite /seafhttp {
        regexp (.*)
        to     {1}
    }
    gzip
    log stdout
    errors stdout
}

Django log file, which handles web uploads/downloads, simply generates lines such as:

[WARNING] django.request:170 get_response Not Found: /upload-aj/082e0997-1537-4326-bc0b-ffab359423f0

Any idea what I’m missing here?

[matt (Matt Holt)]

Hey Patrik, thanks for the question!

I know this sounds stupid (it’s a known issue), but what if you reverse the order of the proxy rules:

proxy /seafhttp 10.0.1.29:8082
proxy / 10.0.1.29:8000 {
    proxy_header Host {host}
    proxy_header X-Forwarded-Proto {scheme}
}

Let me know if that works…

[patrik (Patrik Arvidsson)]

Well look at that. Something so simple…

I think we’re one step closer now. In the UI the upload is just spinning around at completed (unable to save the file I would guess). Seafile is running in a LXD VM under root so there shouldn’t be a permission issue as nginx works. Here’s the output of Caddy:

"GET /seafhttp/protocol-version HTTP/1.1" 404 0

Looking at the django log file, we see this:

[WARNING] django.request:170 get_response Not Found: /upload-aj/6c398328-3256-4b1c-94b2-94fcd85e0699
[WARNING] django.request:170 get_response Not Found: /protocol-version

I’ve tried with and without the rewrite but I’m guessing something’s up with that part because these errors are not generated by nginx, although nginx are unable to upload the files if I remove the rewrite line (instead I get “Unknown error” in Seafile, although no log entry in the django file…).

When I first set up nginx I read a lot about protocol-version as well so another thing that might help to point out is what the URL https://xx.xxxxxx.xx/seafhttp/protocol-version generates.

Nginx: {"version": 1}
Caddy: 404 with Caddy output /seafhttp/protocol-version HTTP/2.0" 404 23

Does that help in any way?

[matt (Matt Holt)]

FYI, with beta 3 (coming soon), the order of the proxy rules will not matter: it will always choose the most specific path to match. See https://github.com/mholt/caddy/pull/114 for the complete history.

Sorry, I’m not sure how to help you with the rest of the Seafile debugging. If you can reduce the problem down to a simpler reproducible case then maybe it will be easier to understand what is going on, but I have not even heard of Seafile before, let alone know how to use it to debug Caddy. :-/

In the meantime, any other Seafile users have any tips?

Once you get it working, you should add a working Caddyfile to GitHub - caddyserver/examples: OBSOLETE. This repo was for Caddy v1. For v2 and newer, see our forum's wiki category..

[patrik (Patrik Arvidsson)]

Looks like we’re out of luck here

Someone who understands what the nginx rules are doing (from here it looks like it’s rewriting requests to /seafhttp to / instead) should be able to translate and write a similar scenario in Caddy, right?

In either case, I’ll keep trying. Thanks for the help so far!

[al-caddyserver (Aleks)]

Hi @patrik your assumption is right.

You need to create a rule / regex which catch /seafhttp(.*) and FORWARD this request to the backend / upstream.

Does this the rewrite block do it (I’m new to caddy ;-)) or is this better?

rewrite /seafhttp {
        regexp  /seafhttp(.*)
        to     {1}
    }

Is there a debug option for the caddy ?

[patrik (Patrik Arvidsson)]

Thank you Aleks, but it sadly didn’t work either.

Just before I had to run to the train I managed to solve the issue. I updated to the new Caddy beta where it was documented that it was now possible to have two different server blocks. My working config looks like this:

xx.xxxxxxx.xx {
    proxy / 10.0.1.29:8000 {
        proxy_header Host {host}
        proxy_header X-Forwarded-Proto {scheme}
    }
    gzip
    log stdout
    errors stdout
}

xx.xxxxxxx.xx/seafhttp {
    proxy / 10.0.1.29:8082 {
       proxy_header Host {host}
       proxy_header X-Forwarded-Proto {scheme}
    }
    rewrite /seafhttp {
        regexp (.*)
        to     {1}
    }
    gzip
    log stdout
    errors stdout
}

When adding things to the Caddy examples it looks like the rewrite isn’t even needed to make this functional. So we can shorten this down to:

xx.xxxxxxx.xx {
    proxy / 10.0.1.29:8000
}

xx.xxxxxxx.xx/seafhttp {
    proxy / 10.0.1.29:8082
}

This doesn’t really make sense to me, but maybe Matt can shed some light on it. I’m glad it works though, so thanks for all the help