Nginx should respect the `X-Forwarded-Proto` header.

[mreiche]

Description of the change

When Nginx respects the headers X-Forwarded-Proto and X-Forwarded-Port, most setups would work out of the box because the headers are already present (like Traefik does).

The original issue came from failing auto-discovery, because Nginx redirects to insecure http scheme adresses MacOSX' accountsd won't follow.

The solution provided by the documentation https://github.com/nextcloud/helm/tree/main/charts/nextcloud#service-discovery-with-nginx-and-ingress is only for Nginx ingress and could be skipped with this change.

It's possible to improve the nginx configuration by respecting the X-Forwarded-Proto header:

map $http_x_forwarded_proto $real_scheme {
	default https;
	https https;
}

location = /.well-known/carddav     { return 301 $real_scheme://$host/remote.php/dav/; }
location = /.well-known/caldav      { return 301 $real_scheme://$host/remote.php/dav/; }

Benefits

• All URLs are directly redirected to the correct public scheme (from Ingress).
• Easier out-of-the-box setup

Possible drawbacks

• The configuration needs to add $real_scheme for every redirect.
• Maybe we need to integrate X-Forwarded-Port as well for instances running different from 443

Additional information

(none)

[joshtrichards]

It somewhat depends on your deployment scenario.

For ingress: https://github.com/nextcloud/helm/tree/main/charts/nextcloud#service-discovery-with-nginx-and-ingress

[mreiche]

Thanks for the link. But this seems to be the setup for Nginx Ingress. I'm using Traefik. The proposed solution is more independent from any Ingress setup and easier to integrate. I've updated the ticket description. Please follow the PR for details.

[joshtrichards]

Okay, even if you’re not using Ingress as a reverse proxy, the general approach remains the same.

The CalDav/CardDav service discovery 301 redirects should be handled by your reverse proxy or, if you’re not using one, by your external web server—that is, wherever TLS termination occurs.

While there are other ways to get this working, the currently documented and supported Nextcloud approach is to implement these redirects on your reverse proxy or external web server.

If you’re using Traefik, you aren’t relying on the Helm-managed Nginx instance for TLS termination. The Helm-managed Nginx isn’t acting as a reverse proxy in this setup and isn’t handling TLS termination.

Thinking more about it more...

Those current redirects in the Helm Nginx should probably be removed to minimize confusion. They only belong there if that Nginx is configured for TLS and externally exposed. I suspect they were ported over from the documented Nginx config in the Admin Manual, which is intended for just that scenario. They don't hurt being there, technically (if an RP is in front), but they no longer serve a functional purpose. The RP still must do it.

There could be an opportunity to revisit the Admin Manual Nginx config and/or the endpoint routing to take a different approach, but that should probably happen there and not in the Helm chart first. ;-) Particularly since there are some other factors, such as parity with the Apache config so that deployments can remain as uniform as possible.

[mreiche]

From a architecture point of view, the webserver (Nginx/Apache) is part of the application server which implements all the application logic, including redirects.

The reverse proxy on the other hand should not care about application logic (like redirects), but on infrastructure like SSL termination, security features, load balancing etc.

It's a common approach of separation of duties.

[joshtrichards]

I understand; I'm saying this isn't within the responsibility of this Helm chart to resolve. It's merely implementing what's currently supported/recommended upstream (by Server).

[mreiche]

I think its the responsibility of the Webserver. I recommend to apply the change (PR), update the documentation and provid a change for Nextcloud AIO as well.