I am trying to run nextcloud with caddy. Here is my config based on what I have seen here
root /var/www/localhost/htdocs/nextcloud
errors /var/log/caddy-errors.log
fastcgi / 127.0.0.1:9000 php
rewrite {
r ^/remote.php/(webdav|caldav|carddav|dav)(\/?)$
to /remote.php/{1}
}
rewrite {
r ^/remote.php/(webdav|caldav|carddav|dav)/(.+)(\/?)$
to /remote.php/{1}/{2}
}
I get to the login page and I can enter the login. Right after that, nextcloud apparently attempts to go to index.php/apps/files and gets into an infinite loop of redirects.
I don’t see this problem if I run with apache and mod_php.
Well, you haven’t given Caddy any redirection instructions and none of those rewrites apply to that path. Those requests would be going to fastcgi… I think. Does your PHP log record anything of note during these redirect loops?
Hrm… Glancing over that .htaccess, you could probably add a header or two and some expires to your Caddyfile, but I don’t see any equivalent to those rewrites. Where do they come from?
rewrite {
r ^/remote.php/(webdav|caldav|carddav|dav)(\/?)$
to /remote.php/{1}
}
rewrite {
r ^/remote.php/(webdav|caldav|carddav|dav)/(.+)(\/?)$
to /remote.php/{1}/{2}
}
But they aren’t the same. The other rewrites look like LetsEncrypt support, actually (not required because Caddy will handle it all). Pull those rewrites out of your Caddyfile (unless you know what they’re for and that they’re required). I doubt it will solve your redirect issue though (those rewrites shouldn’t be affecting that request path).
At this point I suspect Nextcloud itself is the culprit, possibly taking some issue with the headers or the request.
You might as well add the security headers from the .htaccess:
<IfModule mod_env.c>
# Add security and privacy related headers
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set X-Robots-Tag "none"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Download-Options "noopen"
Header set X-Permitted-Cross-Domain-Policies "none"
SetEnv modHeadersAvailable true
</IfModule>
This rewrite rule I am unfamiliar with and can’t say for sure whether it is contributory to your issue, but it seems suspect and I’ve no idea how to replicate its effect in a Caddyfile:
Make sure your cache is cleared each time too. 301 redirects are cached, so if you’re making changes to config but not clearing cache, all your changes need to be redone with a clear cache.
Yeah, Google Chrome definitely caches 301. It’s a real pain if you aren’t aware that it’s happening. You can disable caching while DevTools are open. see: Chrome Clear Redirect Cache
I initially had redirects in nginx, but solved it with using their recommended configuration. This implies the caddy configuration is causing the redirects after all.