Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Extended MKCOL (RFC 5689): detection, testing and 207 handling

Aperta
  • Qualcosa non va?
#702 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
api

Direzione di ricerca

Read RFC 5689 section 3, then inspect Calendar._create() and _async_create() in collection.py, along with the create-calendar description in compatibility_hints.py. Start by tracing how expected return codes and 207 Multi-Status responses are handled; the immediate success criterion is that the code recognizes a created collection and reports property failures. The broader detection and server-tester tasks need separate scoping.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement roadmap

Some history ...

  • Back when the very first versions of the library was implemented, MKCOL was used instead of MKCALENDAR for creating calendars.
  • MKCOL didn't work at all servers. The CalDAV standard specifies that there is a method MKCALENDAR that should be used. I changed the library from using MKCOL to using MKCALENDAR when creating calendars.
  • In January 2026 I asked Claude to make me a list of features that were missing from the caldav library. RFC 5689 was flagged (see the file docs/design/FEATURE_COMPLETE_ROADMAP.md).
  • I forgot about this, but later I discovered that some of the servers where MKCALENDAR doesn't work supports creating calendars through MKCOL, so now there is some logic in there trying both methods.
  • Now, Claude claims that most of the work here is already done.

The very least I need to do here is to read through RFC 5689 and see if I understand it.

AI-generated analysis below the line

⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "3.3 Extended MKCOL (RFC 5689) also needs an issue"

Not a green field — most of it is already there

The roadmap said "support extended MKCOL as an alternative to MKCALENDAR" as if nothing existed. That is wrong, and the roadmap has been corrected: Calendar._create() in collection.py already builds an extended MKCOL request — dav.Mkcol() wrapping a DAV:set/DAV:prop with resourcetype set to collection + calendar, plus display name and supported-calendar-component-set — and uses it instead of MKCALENDAR whenever the server is configured with create-calendar: {support: quirk, behaviour: mkcol-required}. Properties are therefore already set atomically at creation, with a PROPPATCH afterwards only as a fallback.

What is missing is everything around it.

Tasks

  • Nothing detects support. The MKCOL path is only taken when a server profile declares mkcol-required, and exactly one profile does (baikal_old). A server that supports both, or only extended MKCOL, is not discovered — there is no "try MKCALENDAR, fall back to MKCOL on 405/501" and no probe.
  • Nothing tests it. The description of the create-calendar feature in compatibility_hints.py already admits this: "RFC5689 extended MKCOL may also be used to create calendar collections as an alternative to MKCALENDAR. We should consider testing this as well". A caldav-server-tester check would tell us how much of the matrix supports it, which is the input needed for everything else here.
  • A 207 response is treated as an error. RFC 5689 section 3 says that when the collection is created but a property could not be set, the server answers 207 Multi-Status with a propstat per property. Both _create() and _async_create() pass expected_return_value=201, so such a response raises instead of being parsed — we would neither know which property failed nor that the collection exists.
  • Consider a feature flag distinguishing "supports extended MKCOL" from "requires it", since mkcol-required currently conflates the two.
  • Consider whether extended MKCOL for plain (non-calendar) collections belongs on the object API; today only the raw mkcol() method on the client exists.

Worth it?

The honest case against: MKCALENDAR works on nearly everything, and the one profile that needs MKCOL is an old Baikal. The 207 handling is the part with real bite — it is a latent bug rather than a missing feature, and it is cheap. Detection and a server-tester check are the natural companions to it. The rest can wait.

RFC: https://datatracker.ietf.org/doc/html/rfc5689

⚠️ AI-generated by Claude Opus 5 via Claude Code on behalf of tobixen.

Lingua principale
Python
Stelle
412
Fork
113
Merge medio
1g 7h
PR unite (30g)
34

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python-caldav/caldav

Tutte le issue di python-caldav/caldav

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.