Calendar objects can contain multiple VEVENT components

[markcs]

I'm seeing a lot of these errors in the rustical log:

2025-09-17T05:30:41.380885Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/98499377-d975-46c3-9df6-8469badb2a44.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:41.736655Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/1d0da9d0-c0a4-4f9b-a9b1-83d1d89fb6cb.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:42.770844Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/c4572eda-2172-4f17-bf02-f1524275bed1.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:43.158664Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/5d000ca9-441a-4eb2-b3fe-25e3f23d2e6c.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:43.556992Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/f8c0aadf-8bb6-42c3-8e64-91799de504e2.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:44.194368Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/f1672591-1381-408e-a5ac-15353d3938fd.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:44.709031Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/5b09cb93-3351-4873-8892-85a3ee0b377a.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:45.812411Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/4c2be573-7efe-4e8f-a43a-f59b2f8a5047.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:46.924534Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/216872df-b4d7-4a93-9c5b-3f51fa24673c.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:30:53.777079Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/fc2fc60a-70e3-4cd6-9e79-ac8dc2a87c66.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:31:30.619942Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/269ae3e3-be72-4198-8112-bb1e3b26d9f4.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error
2025-09-17T05:31:31.233588Z ERROR http-request{otel.name=PUT /caldav/principal/user/b1a8f394-3033-4b44-b09b-842a9f045bf2/4317ff4d-54f5-44c9-932f-e1ebed205b3e.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error

I have rustical behind a Caddy reverse proxy and this is my config that aims to keep the headers :

           reverse_proxy rustical:4000 {
                 header_up * {>Host}
                 header_up +If-Match {>If-Match}
                 header_up +If-None-Match {>If-None-Match}
                 header_up +If-Unmodified-Since {>If-Unmodified-Since}
                 header_up +If-Modified-Since {>If-Modified-Since}
           }

Any tips on getting this working correctly appreciated

[lennart-k]

Hey, sorry for the frustrating experience.
I'd guess the failing precondition is valid-calendar-data. (Because in some regards I'm checking quite strictly that the fields match the iCal spec)
If that's the case and if you run with the environment variable RUST_LOG=debug you'll get some more logs including the rejected calendar data.
If you can obtain that I'd be curious how that looks, right now I'm assuming there's some missing field.

Sorry forgot to mention that this is only with the latest version on main that's not fully built yet. I'll tell you when.

[lennart-k]

Okay, the version with a bit more logging is online:
ghcr.io/lennart-k/rustical:main@sha256:0ec7def7e900c9741defea92a7e8b59d6762a85d6e1bb4b65a048ac3ba14352b

[markcs]

Thanks!
I created a test event and got the logs from your update build. Does this help?

2025-09-17T09:22:27.837333Z DEBUG http-request{otel.name=PUT /caldav/principal/myuser/b1a8f394-3033-4b44-b09b-842a9f045bf2/24a920a4-f16c-4967-a3e9-41f823add509.ics ua=CalDavSynchronizer/4.6}:put_event{principal="myuser" calendar_id="b1a8f394-3033-4b44-b09b-842a9f045bf2" object_id="24a920a4-f16c-4967-a3e9-41f823add509" user=Principal { id: "myuser", displayname: Some("myuser"), principal_type: Individual, password: Some(Secret), memberships: [] } if_none_match=Some(TypedHeader(IfNoneMatch(Tags("{>If-None-Match}")))) header_map={"host": "cal.myserver.com", "user-agent": "CalDavSynchronizer/4.6", "content-length": "3824", "*": "{>Host}", "accept-encoding": "gzip, br", "authorization": "Basic xxxxx=", "cdn-loop": "cloudflare; loops=1", "cf-connecting-ip": "x.x.x.x", "cf-ipcountry": "AU", "cf-ray": "98078a0b6fffe6d5-MEL", "cf-visitor": "{\"scheme\":\"https\"}", "content-type": "text/calendar; charset=utf-8", "if-match": "\"c71e968d2b444f656f66abb2369c01456c1404cb4076950cbc4b67493927c643\"", "if-match": "{>If-Match}", "if-modified-since": "{>If-Modified-Since}", "if-none-match": "{>If-None-Match}", "if-unmodified-since": "{>If-Unmodified-Since}", "via": "2.0 Caddy", "x-forwarded-for": "x.x.x.x:33288", "x-forwarded-host": "cal.myserver.com", "x-forwarded-proto": "https", "x-real-ip": "x.x.x.x:33288"} body="BEGIN:VCALENDAR\r\nVERSION:2.0\r\nPRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN\r\nBEGIN:VTIMEZONE\r\nTZID:AUS Eastern Standard Time\r\nBEGIN:STANDARD\r\nDTSTART:19700329T030000\r\nRRULE:FREQ=YEARLY;UNTIL=20071231T140000Z;BYDAY=-1SU;BYHOUR=3;BYMINUTE=0;BYM\r\n ONTH=3\r\nTZNAME:AUS Eastern Standard Time\r\nTZOFFSETFROM:+1100\r\nTZOFFSETTO:+1000\r\nEND:STANDARD\r\nBEGIN:STANDARD\r\nDTSTART:20080406T030000\r\nRRULE:FREQ=YEARLY;BYDAY=1SU;BYHOUR=3;BYMINUTE=0;BYMONTH=4\r\nTZNAME:AUS Eastern Standard Time\r\nTZOFFSETFROM:+1100\r\nTZOFFSETTO:+1000\r\nEND:STANDARD\r\nBEGIN:DAYLIGHT\r\nDTSTART:19701025T020000\r\nRRULE:FREQ=YEARLY;UNTIL=20071231T140000Z;BYDAY=-1SU;BYHOUR=2;BYMINUTE=0;BYM\r\n ONTH=10\r\nTZNAME:AUS Eastern Daylight Time\r\nTZOFFSETFROM:+1000\r\nTZOFFSETTO:+1100\r\nEND:DAYLIGHT\r\nBEGIN:DAYLIGHT\r\nDTSTART:20081005T020000\r\nRRULE:FREQ=YEARLY;BYDAY=1SU;BYHOUR=2;BYMINUTE=0;BYMONTH=10\r\nTZNAME:AUS Eastern Daylight Time\r\nTZOFFSETFROM:+1000\r\nTZOFFSETTO:+1100\r\nEND:DAYLIGHT\r\nEND:VTIMEZONE\r\nBEGIN:VEVENT\r\nCLASS:PUBLIC\r\nDESCRIPTION: \r\nDTEND;TZID=AUS Eastern Standard Time:20250917T195500\r\nDTSTAMP:20250917T092230Z\r\nDTSTART;TZID=AUS Eastern Standard Time:20250917T193000\r\nPRIORITY:5\r\nRRULE:FREQ=WEEKLY;COUNT=25;BYDAY=WE\r\nSEQUENCE:1\r\nSUMMARY:test event\r\nTRANSP:OPAQUE\r\nUID:24a920a4-f16c-4967-a3e9-41f823add509\r\nX-MICROSOFT-CDO-BUSYSTATUS:BUSY\r\nBEGIN:VALARM\r\nACTION:DISPLAY\r\nDESCRIPTION:This is an event reminder\r\nTRIGGER:-PT15M\r\nEND:VALARM\r\nEND:VEVENT\r\nBEGIN:VEVENT\r\nCLASS:PUBLIC\r\nDESCRIPTION: \\n\\n \r\nDTEND;TZID=AUS Eastern Standard Time:20250917T195500\r\nDTSTAMP:20250917T092230Z\r\nDTSTART;TZID=AUS Eastern Standard Time:20250917T193000\r\nLOCATION:Microsoft Teams Meeting\r\nPRIORITY:5\r\nRECURRENCE-ID;TZID=AUS Eastern Standard Time:20250917T193000\r\nSEQUENCE:2\r\nSUMMARY:test event\r\nTRANSP:OPAQUE\r\nUID:24a920a4-f16c-4967-a3e9-41f823add509\r\nX-MICROSOFT-CDO-BUSYSTATUS:BUSY\r\nEND:VEVENT\r\nEND:VCALENDAR\r\n"}: rustical_caldav::calendar_object::methods: invalid calendar data:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN
BEGIN:VTIMEZONE
TZID:AUS Eastern Standard Time
BEGIN:STANDARD
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;UNTIL=20071231T140000Z;BYDAY=-1SU;BYHOUR=3;BYMINUTE=0;BYM
 ONTH=3
TZNAME:AUS Eastern Standard Time
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:STANDARD
DTSTART:20080406T030000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYHOUR=3;BYMINUTE=0;BYMONTH=4
TZNAME:AUS Eastern Standard Time
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;UNTIL=20071231T140000Z;BYDAY=-1SU;BYHOUR=2;BYMINUTE=0;BYM
 ONTH=10
TZNAME:AUS Eastern Daylight Time
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:DAYLIGHT
DTSTART:20081005T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYHOUR=2;BYMINUTE=0;BYMONTH=10
TZNAME:AUS Eastern Daylight Time
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
DESCRIPTION:
DTEND;TZID=AUS Eastern Standard Time:20250917T195500
DTSTAMP:20250917T092230Z
DTSTART;TZID=AUS Eastern Standard Time:20250917T193000
PRIORITY:5
RRULE:FREQ=WEEKLY;COUNT=25;BYDAY=WE
SEQUENCE:1
SUMMARY:test event
TRANSP:OPAQUE
UID:24a920a4-f16c-4967-a3e9-41f823add509
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-PT15M
END:VALARM
END:VEVENT
BEGIN:VEVENT
CLASS:PUBLIC
DESCRIPTION: \n\n________________
 ________________________________________________________________\n
DTEND;TZID=AUS Eastern Standard Time:20250917T195500
DTSTAMP:20250917T092230Z
DTSTART;TZID=AUS Eastern Standard Time:20250917T193000
LOCATION:Microsoft Teams Meeting
PRIORITY:5
RECURRENCE-ID;TZID=AUS Eastern Standard Time:20250917T193000
SEQUENCE:2
SUMMARY:test event
TRANSP:OPAQUE
UID:24a920a4-f16c-4967-a3e9-41f823add509
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
END:VEVENT
END:VCALENDAR

2025-09-17T09:22:27.839391Z ERROR http-request{otel.name=PUT /caldav/principal/myuser/b1a8f394-3033-4b44-b09b-842a9f045bf2/24a920a4-f16c-4967-a3e9-41f823add509.ics ua=CalDavSynchronizer/4.6 status=412 Precondition Failed}: rustical::app: client error

[lennart-k]

Thanks that helps a lot.
So in this case it seems to be that caldavsynchronizer tries to upload invalid calendar data.
For some reason it has expanded the event to the next occurence (note how there are two BEGIN:VEVENT)
even though CalDAV spec says that calendar objects must not contain more than one VEVENT instance https://www.rfc-editor.org/rfc/rfc4791#section-4.1
:(

[4.1](https://www.rfc-editor.org/rfc/rfc4791#section-4.1).  Calendar Object Resources

   Calendar object resources contained in calendar collections MUST NOT
   contain more than one type of calendar component (e.g., VEVENT,
   VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
   components, which MUST be specified for each unique TZID parameter
   value specified in the iCalendar object.  For instance, a calendar
   object resource can contain one VEVENT component and one VTIMEZONE
   component, but it cannot contain one VEVENT component and one VTODO
   component.  Instead, the VEVENT and VTODO components would have to be
   stored in separate calendar object resources in the same collection.

[markcs]

I saw that, but it validates at https://icalendar.org/validator.html

[lennart-k]

That's true. it's a restriction by the CalDAV spec and not the iCalendar spec.
In general allowing multiple events in a calendar is also needed to allow exports or to fetch recurring events in expanded form,
but for PUTing calendar objects in CalDAV it has to be only one. :/

[lennart-k]

I think these issues might be related
aluxnimm/outlookcaldavsynchronizer#437
aluxnimm/outlookcaldavsynchronizer#276

[markcs]

okay. Thanks for linking those issues.
I note that caldavsynchronizer works with Radicale and Nextcloud, so I guess they are not following the specs as closely or have some work around to allow this

[lennart-k]

Yeah, Radicale just ignores all but the first event but also just blindly saves it in its wrong form.
I definitely don't want to do that since that just leaves us in a wrong state.
As a workaround I could imagine a more lenient mode where on PUT the input is modified to remove all following events but that also doesn't feel right.
I'd very much prefer a fix on outlookcaldavsynchronizer's side such that it uploads valid data. :)

[lennart-k]

Let's entertain the idea of trying to provide a workaround:
In the example there are basically two revisions of the same event as indicated by SEQUENCE.
Correctly, we want to pick the latest revision which would be the latter event with SEQUENCE=2.

Radicale on the other hand (which uses the vobject library under the hood) would pick the first revision which makes it even more wrong.

So I'd argue that Radicale basically hides that things are going wrong.

If I was to provide a workaround I'd pick the latter one because that's the latest revision. However, that behaviour would also be different from Radicale (and probably many other servers for that matter too).

[lennart-k]

Oh, so I just found out that in RFC 6648 (Scheduling Extensions for CalDAV) there is an exception to the rule from CalDAV for Inbox collections.
I'll have to read up a bit to see what that implies exactly.

[lennart-k]

Okay, I understand that this is not in conformance with the original CalDAV spec but still well-defined behaviour defined somewhere else.
In the example you probably had some recurring event with an alarm but disabled the alarm for a specific recurrence.