CalDAV discovery fails on iOS behind reverse proxy due to .well-known redirect scheme/port

[tommyolly]

Checklist

• I have used the search function for OPEN issues to see if someone else has already submitted the same bug report.
• I have also used the search function for CLOSED issues to see if the problem is already solved and just waiting to be released.
• I will describe the problem with as much detail as possible.
• This is not about the docker image. In that case, contact the authors of the docker image.

Baikal version

Baïkal 0.10.1

PHP version

PHP 8.x

Steps to reproduce

1. Deploy Baïkal using the standard nginx configuration provided in the project documentation.
2. Place Baïkal behind a reverse proxy / HTTPS terminator (in this case Tailscale Serve), so Baïkal itself listens on HTTP internally while clients connect via HTTPS on a non-standard port.
3. Configure a CalDAV account on iOS (Settings → Calendar → Accounts → Add Account → CalDAV) pointing to the Baïkal server.
4. Observe that iOS Calendar reports “Unable to update calendars”.
5. From the same iOS device, subscribe to the same calendar via an ICS URL exposed by Baïkal.
6. Observe that the subscribed calendar works correctly and updates as expected.

Expected behaviour

iOS Calendar should successfully discover the CalDAV endpoint via /.well-known/caldav, complete principal and calendar-home-set discovery, and allow read/write access to the calendar when valid credentials are supplied.

Current behaviour

iOS Calendar fails CalDAV discovery and reports “Unable to update calendars”.

Inspection shows that requests to /.well-known/caldav are redirected to /dav.php using an absolute Location header that does not preserve the external HTTPS scheme and/or port when Baïkal is behind a reverse proxy.

Linux CalDAV clients (e.g. GNOME Calendar, DAVx5) are tolerant of this and work correctly, but Apple’s CalDAV client is strict and fails discovery.

Direct access to the calendar via ICS works correctly, confirming that server-side data, authentication, and SabreDAV are functioning as expected.

Logs

curl -I https://:/.well-known/caldav

Returns a 301/302 redirect to http:///dav.php (scheme downgrade and/or port loss).

Replacing the rewrite-based redirect with an explicit HTTPS-preserving redirect resolves the issue immediately on iOS.

This appears to be a deployment-agnostic issue, as reverse proxies and HTTPS termination are common setups. Adjusting the default nginx configuration so that redirects from /.well-known/caldav and /.well-known/carddav preserve the externally visible scheme, host, and port would improve interoperability (notably with iOS) without affecting non-proxied installs.

[tommyolly]

After some testing, this turned out to be entirely the /.well-known/caldav and /.well-known/carddav redirects in the nginx config when Baïkal is behind TLS termination on a non-standard port (Tailscale Serve on :9443 in my case). iOS Calendar was failing discovery because the redirect Location was being generated as http://…/dav.php (and could drop the port), even though the external URL was https://…:9443. I fixed it by overriding /etc/nginx/conf.d/default.conf and changing only those two lines to explicitly return https://$http_host/dav.php for both caldav and carddav. After recreating the container and re-adding the CalDAV account on iOS (to clear cached discovery), iOS read/write works reliably.