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

Support managed attachments (RFC 8607)

Aperta
#700 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
python

Direzione di ricerca

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.

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

Descrizione

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.

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

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.