Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#702 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
412
Forks
113
Merge medio
22 h 43 min
PR fusionados (30 d)
43

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python-caldav/caldav

Todos los issues de python-caldav/caldav

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.