Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#702 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
api

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
412
フォーク
113
平均マージ
1日 2時間
マージ済み PR（30日）
43

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

python-caldav/caldav のほかの issue

python-caldav/caldav の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。