Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Keep the server's raw bytes, and allow sending given bytes unchanged

Open
  • Is something wrong?
#763 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Start with _set_data() around line 1760 in calendarobjectresource.py and trace the GET, calendar-query, calendar-multiget, and save paths that call it or normalize data with vcal.fix(). The issue leaves the API shape open, so first read the linked calendaring design and compare these paths. Done means preserving the received bytes and offering an opt-in to send supplied bytes unchanged while retaining conditional request handling.

Written by the indexing model from the issue text.

Description

enhancement

Disclaimer: AI-generated text below the line, generated by Claude Opus 5.5 (Claude Code), from the prompt:

Open the issue in the caldav library [comment made in a code-review document, on a finding that caldav's wire_data is not the bytes the server sent]

Low priority. Needed by the calendaring library's proposed Item.wire (https://github.com/pycalendar/calendaring, docs/design/API_DESIGN.md, "The stored form"), and by sync tools such as https://github.com/pycalendar/calendaring-sync, which compare and push the bytes a server stores.

Today a CalendarObjectResource cannot give back what the server sent:

  • _set_data() runs the incoming data through vcal.fix() before storing it in _data (calendarobjectresource.py, around line 1760), so the raw response body is gone right after parsing the response.
  • wire_data re-encodes _data (or serialises icalendar_instance / vobject_instance after an edit), so it is caldav's normalised copy, not the server's bytes, and not a snapshot of what was read.
  • When saving, the same path normalises bytes the caller passes in, so "store exactly these bytes" is not possible either.

Suggested shape (open for discussion):

  • Keep the unmodified response body of the last GET / calendar-query / calendar-multiget in a read-only attribute (e.g. raw_data), cleared by any write or local edit, next to the etag it belongs to.
  • An opt-in to send given bytes without vcal.fix() (e.g. save(raw=True), or setting raw_data before save()), still with If-Match / If-None-Match.

vcal.fix() stays the default; this is only about not throwing the original away.

Dominant language
Python
Stars
412
Forks
113
Avg merge
1d 7h
Merged PRs (30d)
34

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python-caldav/caldav

All issues in python-caldav/caldav

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.