Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#702 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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 小时
30 天内合并 PR
43

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

python-caldav/caldav 的其他 Issue

查看 python-caldav/caldav 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。