-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maybe document subfolder based access (example) #2276
Comments
Current setup: |
There are a couple of ways of approaching this, but here's the one I just tested.
In the examples below, the Caddy work definitely works (I just tested it). The Nginx should work / should be equivalent: [1] Reverse proxy configurations: Nginx
Note: the backslash above is critical otherwise the URI prefix will not be stripped. Ref: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass Caddy
Ref: https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#examples |
Hi @joshtrichards , can you please share which docker image flavour and version you have used? Was it apache/fpm/nginx/alpine/... ? Best, |
The above was with:
The app and web container combination shouldn't make much difference (should work equally well with the apache one). All the heavy lifting to support this is being done by:
|
Caddy and the nextcloud:fpm image is a non-obvious combination. After debugging until 3am, I found out that Caddy is not stripping the path from the CGI environment variable REQUEST_URI, but only from PATH_INFO. The maker of Caddy insists that is how the spec works and other software would need to be fixed (here php-fpm or nextcloud). More info here: https://help.nextcloud.com/t/nextcloud-docker-compose-setup-with-caddy-2024/204846/10?u=rriemann |
Note I am referring to Caddy (or Nginx) at the reverse proxy layer, not as the web server. In my test case, a standard1 nginx server (i.e. running a typical Nextcloud nginx config) remained at the web server layer (itself connected to fpm). In theory the reverse proxy and web layers could be merged, as in any Nextcloud deployment, but I did not test that. Also, it makes it universally useful with either edition of our image. ---
title: FPM image (web+fpm)
---
graph TB
reverse_proxy --> web
web --> fpm
---
title: Apache image (web+mod_php)
---
graph TB
reverse_proxy --> web+mod_php
Footnotes
|
There's a distinction between a subfolder installation of Nextcloud (i.e. somewhere under the docroot) and merely making Nextcloud reachable via a subfolder style URL (https://domain.tld/nextcloud). The former is not something relevant to this image, while the latter is a config matter (including reverse proxy integration)
There's probably an opportunity to improve upstream documentation and/or our docs & examples here at the Docker level.
I mention this so that maybe we can finally close out the following issues:
The text was updated successfully, but these errors were encountered: