Discovery never tries the address typed, so a server under a sub-path without a root /.well-known cannot connect #23

New issue

Closed

opened 2026-10-01 10:47:53 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-01 10:47:53 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo-dav at 97abc9779, reading discovery and running Test against a fake server that only answers under a sub-path.

Server.principal() asks for the principal at /.well-known/{carddav|caldav} and at /, both absolute paths, so urljoin resolves them against the host's root and the path in the configured address is never used. A DAV server installed under a sub-path (Baïkal at /dav.php/, SOGo at /SOGo/dav/, Nextcloud or Radicale behind a prefix) whose web server has no redirect at the root cannot be connected at all, even when the person types the exact DAV endpoint.

Where: src/postulo_dav/dav.py:126-137 (Server.principal, for start in (f"/.well-known/{well_known}", "/"):); the address is described at src/postulo_dav/sync.py:231-241 (config_fields, "The server's root, e.g. https://cloud.example.org. Postulo finds the address book and calendar homes from there.") and in README.md:33.
What happens: a person types https://example.org/baikal/dav.php/. Test sends PROPFIND to /.well-known/carddav and to / on example.org, both answer 404, and the result is "DavError: the server names no principal for carddav". No request is made under /baikal/. Reproduced with a mock transport that answers 404 everywhere and logs paths: the only two requests were /.well-known/carddav and /.
Why it matters: the README names Baïkal and SOGo among the supported servers, and those are commonly installed under a path; such a person has no address they can type that works, while their other DAV clients connect.
Fix: in principal(), try the configured address itself first (self.base, a relative start), then /.well-known/…, then /. Reword the help text to say that either the server's root or its DAV address will do.

Done when

A test in tests/test_dav.py with a fake server that serves the DAV tree only under a sub-path and answers 404 at the root and at /.well-known/, asserting that Test with the sub-path address finds both collections.

Found on 2026-09-29 in a read-only review of postulo-dav at 97abc9779, reading discovery and running *Test* against a fake server that only answers under a sub-path. `Server.principal()` asks for the principal at `/.well-known/{carddav|caldav}` and at `/`, both absolute paths, so `urljoin` resolves them against the host's root and the path in the configured address is never used. A DAV server installed under a sub-path (Baïkal at `/dav.php/`, SOGo at `/SOGo/dav/`, Nextcloud or Radicale behind a prefix) whose web server has no redirect at the root cannot be connected at all, even when the person types the exact DAV endpoint. - **Where:** `src/postulo_dav/dav.py:126-137` (`Server.principal`, `for start in (f"/.well-known/{well_known}", "/"):`); the address is described at `src/postulo_dav/sync.py:231-241` (`config_fields`, "The server's root, e.g. https://cloud.example.org. Postulo finds the address book and calendar homes from there.") and in `README.md:33`. - **What happens:** a person types `https://example.org/baikal/dav.php/`. *Test* sends PROPFIND to `/.well-known/carddav` and to `/` on `example.org`, both answer 404, and the result is "DavError: the server names no principal for carddav". No request is made under `/baikal/`. Reproduced with a mock transport that answers 404 everywhere and logs paths: the only two requests were `/.well-known/carddav` and `/`. - **Why it matters:** the README names Baïkal and SOGo among the supported servers, and those are commonly installed under a path; such a person has no address they can type that works, while their other DAV clients connect. - **Fix:** in `principal()`, try the configured address itself first (`self.base`, a relative start), then `/.well-known/…`, then `/`. Reword the help text to say that either the server's root or its DAV address will do. ## Done when - A test in `tests/test_dav.py` with a fake server that serves the DAV tree only under a sub-path and answers 404 at the root and at `/.well-known/`, asserting that *Test* with the sub-path address finds both collections.

tiagoagueda added this to the 0.5.0 milestone

2026-10-01 10:47:53 +00:00

tiagoagueda added the

bug

label

2026-10-01 10:47:53 +00:00

tiagoagueda referenced this issue from a commit

2026-10-19 07:13:10 +00:00

Review fixes: pairing by UID, bounded reads, per-resource tolerance, notes per reader, and a calendar that carries no attendee

tiagoagueda referenced this issue

2026-10-19 07:13:15 +00:00

Review fixes: pairing by UID, bounded reads, notes per reader, per-resource tolerance #35