iCloud: URL.join raises "can't be joined" when REPORT hrefs use caldav.icloud.com after client.url was rewritten to the pNN partition host
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- python
- Ambito
- backend, networking
Direzione di ricerca
Start by reading caldav/lib/url.py around URL.join, caldav/davobject.py around DAVObject.__init__, and the iCloud handling in collection.py near calendar_home_set and _post_request_report_build_resultlist. Use the provided no-network reproduction to confirm the hostname mismatch, then add a regression test for an absolute iCloud href on the alternate host. Done means same-service iCloud URLs are handled without weakening rejection of unrelated host mismatches.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Disclosure (per AI-POLICY.md): this bug was hit on my Home Assistant install. The diagnosis, the reproduction script and the suggested fix below were produced with Claude (Anthropic, via Claude Code); I've checked the results against my live setup. I'm happy to answer questions and test a fix.
What happens
With iCloud, searches on a calendar intermittently fail with:
ValueError: https://p49-caldav.icloud.com:443/12345678/calendars/ can't be joined with https://caldav.icloud.com/12345678/calendars/<calendar-uuid>/<event-uuid>.ics
Traceback (caldav 3.3.0a1, as pinned by Home Assistant 2026.10.0; the same code is on master at b8497e9):
File "caldav/collection.py", line 1864, in search
File "caldav/search.py", line 999, in search
...
File "caldav/collection.py", line 1663, in _request_report_build_resultlist
File "caldav/collection.py", line 1640, in _post_request_report_build_resultlist
File "caldav/calendarobjectresource.py", line 171, in __init__
File "caldav/davobject.py", line 108, in __init__
File "caldav/lib/url.py", line 264, in join
raise ValueError("%s can't be joined with %s" % (self, path))
Once it starts, every search fails until the client is rebuilt. In Home Assistant that means the calendar entity is unavailable until a restart. I saw two windows of about 1–2.5 hours on one day.
Why
- The client is created with
url="https://caldav.icloud.com". calendar-home-setcomes back on the account's partition host (https://p49-caldav.icloud.com:443/12345678/calendars/). The setter inPrincipal.calendar_home_set(the "Here be dragons" block incollection.py) then rewritesclient.urlto that host.- iCloud does not always use the same host in its responses. When I query the generic host, every href in a REPORT response is absolute on
caldav.icloud.com(36 of 36 in one test). When the client talks to the partition host, the hrefs normally match it. Sometimes, though, a response to the partition host contains hrefs oncaldav.icloud.com. DAVObject.__init__doesclient.url.join(url), andURL.joinraises whenever the hostnames differ.
The two hosts serve the same account, so the href is valid. It just names the other front end.
Minimal reproduction (no network)
from caldav import DAVClient
from caldav.calendarobjectresource import Event
client = DAVClient(url="https://p49-caldav.icloud.com/12345678/calendars/", username="u", password="p")
Event(client, url="https://caldav.icloud.com/12345678/calendars/cal/event.ics")
# ValueError: https://p49-caldav.icloud.com/12345678/calendars/ can't be joined with https://caldav.icloud.com/12345678/calendars/cal/event.ics
The same thing happens with a Calendar whose URL is on the generic host.
Suggested fix
When an href is absolute but on a different host, and both hosts are the same service (for iCloud: both end in .icloud.com, same scheme), join by path onto the client's host instead of raising. Requests then only ever go to the host the client already uses, so no request (and no credential) goes to a new host. Every other host mismatch still raises, which keeps the protection join gives today.
As a local workaround I'm wrapping URL.join like this:
_original_join = URL.join
def _join(self, path):
try:
return _original_join(self, path)
except ValueError:
other = URL.objectify(path)
if other is None:
raise
hosts = (self.hostname or "", other.hostname or "")
if not all(h.endswith(".icloud.com") for h in hosts) \
or (self.scheme or "https") != (other.scheme or "https"):
raise
return _original_join(self, other.path + (f"?{other.query}" if other.query else ""))
A cleaner upstream fix might belong where the "icloud hack" already lives in _post_request_report_build_resultlist, or in the calendar_home_set setter. One option is to remember the original host as an alias of the rewritten one, so hrefs on either host are accepted. I'm happy to turn this into a PR with a test if you tell me which approach you prefer.
Environment
- caldav 3.3.0a1 (Home Assistant 2026.10.0, Python 3.14); same
URL.joinandDAVObject.__init__logic on master b8497e9 - Server: iCloud (
caldav.icloud.com→ partitionp49-caldav.icloud.com)
- Lingua principale
- Python
- Stelle
- 412
- Fork
- 113
- Merge medio
- 2g 4h
- PR unite (30g)
- 19
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di python-caldav/caldav
-
Todo.complete(rrule_mode="this_and_future") raises AttributeError; only the undeclared "thisandfuture" worksForse già presa @muratatar06 l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
python-caldav/caldav#735 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
python-caldav/caldav#687 ·
I maintainer di solito rispondono entro 1 giorno
-
get_calendars() returns [] for a Nextcloud public calendar share (regression from 2.x)Forse già presa @IT-BAER l’ha presa 1 giorno fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
python-caldav/caldav#743 ·
I maintainer di solito rispondono entro 1 giorno
-
delete() sends no If-Match, so a concurrent change is deleted silentlyForse già presa @tobixen l’ha presa oggi. Aperta
Difficoltà 3/5 Mezza giornata Idoneità per principianti 22/100
python-caldav/caldav#740 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
python-caldav/caldav#739 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di python-caldav/caldav
Issue simili
-
Claiming namespace `jft63`Apertanamespace operations
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
EclipseFdn/open-vsx.org#14043 ·
I maintainer di solito rispondono entro 1 giorno
-
netbox status: needs triage type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
netbox-community/netbox#23376 ·
I maintainer di solito rispondono entro 1 giorno
-
feedback simulation workshop
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
githubnext/gh-aw-workshop#4455 ·
I maintainer di solito rispondono entro 1 giorno
-
Triage 🩺
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Container scenario crashes without expected_recovery_time, kube DNS example uses retry_waitApertaneeds-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
krkn-chaos/krkn#1627 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno