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

Support managed attachments (RFC 8607)

未关闭
#700 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
python

调研方向

Start with section 3.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md and RFC 8607, then inspect tests/test_caldav_unit.py for the existing inline ATTACH fixture. First decide whether managed attachments are worth supporting and what the API should accept and return; if proceeding, done means implementing the listed detection, operations, object methods, limits and compatibility hints, with tests that can skip on unsupported servers.

由索引模型根据 Issue 内容生成。

描述

enhancement roadmap

The task is to do research on RFC 8607, assess if it's relevant for the caldav library, and (if it's deemed worth it) implement support. Claude has already done some research, see the findings below.


⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "3.1 managed attachments needs an issue"

Tracking issue for section 3.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md, which had no issue behind it.

There is no attachment support in the library today — no hits for ATTACH, MANAGED-ID or attachment anywhere in caldav/.

Scope: managed attachments, not attachments in general

Worth separating two things that both go by "attachment":

  • Inline / URI ATTACH (RFC 5545) — a plain iCalendar property, either a URI or base64 binary. This already works, in the sense that the library treats it as opaque iCalendar data and hands it to icalendar; tests/test_caldav_unit.py even has a large base64 ATTACH fixture. Nothing to implement, though convenience accessors could be argued for.
  • Managed attachments (RFC 8607) — the attachment is stored server-side, outside the calendar object. The client POSTs the file to a separate URL, the server answers with an ATTACH property carrying a MANAGED-ID, and add/update/remove are HTTP POSTs with ?action=attachment-add|attachment-update|attachment-remove. This is what is missing, and it is what this issue is about.

Tasks

  • Detect server support — the CALDAV:managed-attachments-server-URL property, and the calendar-managed-attachments token in the DAV: header
  • attachment-add, attachment-update, attachment-remove POST operations
  • Handle MANAGED-ID, and the FMTTYPE / FILENAME / SIZE parameters
  • event.add_attachment() / event.remove_attachment() on the object API
  • Respect the server's max-attachment-size and max-attachments-per-resource limits, and give a decent error when they are exceeded
  • Compatibility hints, so the tests skip rather than fail
  • Decide what the API takes and returns — a path, a file object, or bytes; and whether a download streams or buffers

Why this may not be worth doing soon

The roadmap already rates it low priority, and I think that is right:

  • Server support is thin. Apple Calendar Server implements it; most of the servers in the docker test matrix do not, so most of the work would be untestable.
  • It drags file handling into a library that currently only moves text around — streaming, temp files, memory limits for large blobs. That is a real API design question, not just a protocol binding.
  • The people who ask for attachments usually mean inline ATTACH, which already round-trips.

So: worth having the issue so section 3.1 is not an orphan, but not obviously worth doing before ACL, alarms or the robustness work.

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

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

主要语言
Python
星标
412
派生
113
平均合并
1 天 14 小时
30 天内合并 PR
26

环境准备

  • 没有 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 摘要。