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

Parse server iCalendar through vcal.parse_ical() consistently

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

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
python
领域
backend-api-design

调研方向

Start by reading the existing vcal.parse_ical() implementation and its four current call sites, then inspect the server-fed parsing paths named in caldav/jmap/objects/calendar_object.py, caldav/datastate.py and caldav/calendarobjectresource.py. Clarify whether the scope includes vobject parsing, caller-supplied calendars, and a tree-wide enforcement test; done means the agreed server-fed paths use consistent errors without changing the stated malformed-calendar boundary.

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

描述

refactoring

Issue below was AI-generated, the introduction has been hand-edited

vcal.parse_ical() was added to handle CalDAV-noise before it would
cause a ValueError exception coming from the icalendar library.
The "CalDAV-noise" can be a body with no iCalendar in it - an empty
scheduling-inbox object, an HTML error page delivered with a 200, a
notification carrying only headers, etc. parse_ical() raises
error.ResponseError instead, quoting what arrived and the URL where
one is known.

It is currently used at four of the parse sites, and there are others that still
hand data to the parser directly. Anything that can be fed by a server should go
through the guard, so the error is the same everywhere.

Sites still parsing directly

  • caldav/jmap/objects/calendar_object.py:64 -
    icalendar.Calendar.from_ical(jscal_to_ical(self.data)). Server-fed: self.data
    is JSCalendar from a JMAP response, so a server that returns something
    unconvertible lands here. This is the one that matters.
  • caldav/datastate.py:140, :192, :228 and
    caldav/calendarobjectresource.py:1612 - vobject.readOne(...). Same data,
    different parser, same problem: an empty body gives a vobject error that says
    nothing about where it came from. A parse_vobject() counterpart, or one guard
    the two share, would cover it.
  • caldav/lib/vcal.py:243 (inside create_ical()) and
    caldav/jmap/convert/ical_to_jscal.py:306 - both parse iCalendar the caller
    supplied, not a server response. Arguably these should keep raising whatever
    icalendar raises, since a broken fragment there is a client-side bug, not a
    server one. Worth deciding explicitly rather than by omission.

Points worth deciding

  • Should the guard fire on the JSCalendar side too - a JMAP response that
    converts to no components at all - or only once it has become iCalendar?
  • parse_ical() is deliberately narrow: it fires only when the body holds no
    BEGIN: line, and hands anything containing a component to icalendar unchanged.
    That boundary should stay wherever it is applied, so that a genuinely malformed
    calendar is not reclassified as a server error.
  • A test that walks the module tree and fails on a bare
    icalendar.Calendar.from_ical( / vobject.readOne( outside the guard would keep
    this from drifting back. Cheap, and the kind of rule that only holds if it is
    enforced.
主要语言
Python
星标
412
派生
113
平均合并
1 天 7 小时
30 天内合并 PR
34

环境准备

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