CalDAV/CardDAV URLs missing /caldav/ and /carddav/ suffix - GNOME Online-Accounts (Linux)

[cryinkfly]

Description
When accessing CalDAV or CardDAV through OpenCloud, the current documentation lists the base URL without the required /caldav/ or /carddav/ suffix. Users attempting to use the base URL directly receive a 403 Forbidden error from the Radicale server.

Steps to reproduce

1. Deploy OpenCloud with Radicale.
2. Access CalDAV via the URL: https://<your.opencloud.domain>/
3. Observe a 403 Forbidden response in the logs or via client access.

Expected behavior
Documentation should indicate the proper URLs:

• CalDAV: https://<your.opencloud.domain>/caldav/
• CardDAV: https://<your.opencloud.domain>/carddav/

Actual behavior
Without /caldav/ or /carddav/, access is forbidden even though users exist in Radicale.

• Tested under Podman (rootless) on Linux.
• Nginx Proxy Manager (NPM) handles standard ports: 443, 80, 81.
• Using /caldav/ and /carddav/ suffix works correctly.
• Reverse proxy properly forwards authenticated users via X-Remote-User.
• Radicale configuration and storage is standard multifilesystem (/var/lib/radicale/collections).
• Nginx Proxy Manager, OpenCloud, and Radicale must be in the same network for proper routing (as in the example radicale:5232 in proxy settings).
• After restarting OpenCloud or making changes in Nginx Proxy Manager (NPM), it may be necessary to temporarily disable and then re-enable the domains so that OIDC/token-based authentication works correctly.

NPM / Proxy Configuration for the opencloud container

# CalDAV
location /caldav/ {
    proxy_pass http://radicale:5232/;
    proxy_set_header X-Remote-User $remote_user;
    proxy_set_header X-Script-Name /caldav;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location /.well-known/caldav {
    proxy_pass http://radicale:5232/;
    proxy_set_header X-Remote-User $remote_user;
    proxy_set_header X-Script-Name /caldav;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# CardDAV
location /carddav/ {
    proxy_pass http://radicale:5232/;
    proxy_set_header X-Remote-User $remote_user;
    proxy_set_header X-Script-Name /carddav;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location /.well-known/carddav {
    proxy_pass http://radicale:5232/;
    proxy_set_header X-Remote-User $remote_user;
    proxy_set_header X-Script-Name /carddav;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

GNOME Online Accounts – CalDAV & CardDAV Setup

1. Add CalDAV (Calendar) Account

• Open Settings → Online Accounts → Add Account → Custom
• URL: https://<your.opencloud.domain>/caldav/
• Enter username and password (create a self-generated App Token via your cloud’s web interface)
• In the account settings, enable only Calendar sync

2. Add CardDAV (Contacts) Account

• Open Settings → Online Accounts → Add Account → Custom
• URL: https://<your.opencloud.domain>/carddav/
• Enter username and password (create a self-generated App Token via your cloud’s web interface)
• In the account settings, enable only Contacts sync

---

Screenshots

[micbar]

@dragotin Can you help with that?

[cryinkfly]

@dragotin Can you help with that?

I once compared with Thunderbird and found that there, the CalDAV and CardDAV accounts also have to be added separately. Apparently, this is due to the way the OpenCloud container works in conjunction with the proxy.yaml: GOA expects a directly functioning DAV endpoint without redirection to the web interface. A DAV client is indeed forwarded by the proxy to /caldav/ or /carddav/, but the 302 redirect to .web can sometimes confuse GOA, especially if the headers or authentication are not exactly correct.

I also tried editing the proxy.yaml in a simple way, for example by setting redirect_to: /caldav/, but then the container would not start at all. Apparently, OpenCloud is very sensitive to the structure of the proxy.yaml — incorrect fields or redirects without the proper headers cause the container to exit with code 1.

I also tried mapping both /caldav/ and /carddav/ to a single /dav/ endpoint, but so far this has not worked either.

[KintsugiUwU]

I think this is a Gnome Online Account issue

[micbar]

I reproduced this against a stock deployment of this repo (opencloud 7.5.0 + radicale/radicale.yml + the proxy routes from config/opencloud/proxy.yaml) and replayed the request sequence a DAV client walks through. Findings:

Request	Result
PROPFIND /caldav/, /carddav/ (authenticated)	✅ 207, correct current-user-principal
GET/PROPFIND /.well-known/caldav (authenticated)	✅ 301 → /caldav/ (RFC 6764 redirect from Radicale)
GET /.well-known/caldav unauthenticated	❌ 401 — the proxy blocks the request before Radicale can answer the discovery redirect
/caldav without trailing slash	❌ falls through to the web UI (405 on PROPFIND / HTML on GET) — the proxy route only matches /caldav/
bare base URL /	❌ web UI — nothing DAV-shaped, which is why entering just the domain fails in clients without RFC 6764 discovery
account password (default PROXY_ENABLE_BASIC_AUTH=false)	❌ 401
App Token (default config)	✅ 207 — works out of the box

So you're right on both counts: the URLs including /caldav/ / /carddav/ (with the trailing slash) were never documented, and GNOME Online Accounts additionally needs the two services as two separate accounts because it expects a directly answering endpoint per account.

#377 addresses this:

• new radicale/README.md with the client URLs, the App-Token requirement, GNOME Online Accounts + Thunderbird walkthroughs, and a troubleshooting table
• the two /.well-known/* routes are now unprotected: true, so clients that implement RFC 6764 discovery get the 301 redirect before authenticating (previously: 401). Verified that Radicale serves nothing but the redirect on these paths — deeper paths return 404 and path traversal is normalized onto the protected routes.

Slash-less routes (/caldav without trailing slash) were tested and deliberately not added: Radicale answers PROPFIND on the bare script root with a 500, which is worse than the current well-defined behavior — the docs call out the trailing slash instead.

Two notes on your NPM setup (outside this repo's scope, but important):

1. ⚠️ Your NPM config forwards X-Remote-User: $remote_user — nginx fills $remote_user from the client's Authorization header without validating the password unless auth_basic is configured on that location. As written, anyone who can reach those locations can impersonate any Radicale user by sending a crafted Basic-auth header. In this repo's setup the opencloud proxy validates the App Token first and overwrites the header (verified — a client-supplied X-Remote-User never reaches Radicale on authenticated routes).
2. The redirect_to experiments crashing the container: proxy.yaml only supports the route options used in config/opencloud/proxy.yaml (endpoint, backend, unprotected, remote_user_header, skip_x_access_token, additional_headers, …) — unknown fields make the proxy refuse to start.