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.
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.
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.
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?
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!
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: