With a little help from my AI friends.
Description
The CalDAV server returns calendar object URLs containing a percent-encoded @ character in DAV:href, but subsequently fails to resolve those same URLs in a calendar-multiget request.
This prevents clients such as Mozilla Thunderbird from downloading the affected events.
Steps to reproduce
Create a calendar object whose resource filename contains @, for example:
abc123@example.com.ics
Request the calendar collection or perform the initial CalDAV synchronization.
The server returns the object using an encoded DAV:href:
<D:href>/caldav/users/example/calendars/1/abc123%40example.com.ics</D:href>
Send a calendar-multiget request using exactly that returned href:
<?xml version="1.0" encoding="UTF-8"?>
<C:calendar-multiget
xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:prop>
<D:getetag/>
<C:calendar-data/>
</D:prop>
<D:href>/caldav/users/example/calendars/1/abc123%40example.com.ics</D:href>
</C:calendar-multiget>
Actual result
The server responds with:
<D:response>
<D:href>/caldav/users/example/calendars/1/abc123%40example.com.ics</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>
Thunderbird consequently treats the event as missing or deleted:
CalDAV: skipping unfound deleted item:
.../abc123@example.com.ics
The calendar object itself still exists. A full calendar-query can return its calendar-data successfully, so the failure appears specific to resource lookup through calendar-multiget.
Expected result
Any DAV:href returned by the server must be usable in subsequent CalDAV requests.
The calendar-multiget request should return HTTP 200 and the corresponding calendar-data:
<D:response>
<D:href>/caldav/users/example/calendars/1/abc123%40example.com.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>...</D:getetag>
<C:calendar-data>...</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
Impact
Affected events are stored on the server but remain invisible in Thunderbird.
Initial synchronization and forced resynchronization do not help.
Clients may incorrectly consider the affected resources deleted.
All resources whose filenames contain @ can be affected.
Suggested fix
Normalize or decode resource paths consistently when processing calendar-multiget requests.
In particular:
Parse each supplied DAV:href.
Decode percent-encoded path segments exactly once.
Resolve %40 to the same stored resource as @.
Ensure the lookup logic uses the same URI normalization rules as the code that generates DAV:href.
Add a regression test covering filenames such as:
event@example.com.ics
event%40example.com.ics
The test should verify that an href returned during collection discovery can be passed unchanged to calendar-multiget and produces a successful response.
Environment
Client: Mozilla Thunderbird using native CalDAV support
Request type: calendar-multiget
Calendar objects: valid VEVENT resources
Authentication and collection discovery: successful
Full calendar query: successful
Individual multiget lookup for percent-encoded hrefs: 404 Not Found
