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

1. Create a calendar object whose resource filename contains @, for example:

abc123@example.com.ics

2. Request the calendar collection or perform the initial CalDAV synchronization.
3. The server returns the object using an encoded DAV:href:

<D:href>/caldav/users/example/calendars/1/abc123%40example.com.ics</D:href>

4. 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:

1. Parse each supplied DAV:href.

2. Decode percent-encoded path segments exactly once.

3. Resolve %40 to the same stored resource as @.

4. Ensure the lookup logic uses the same URI normalization rules as the code that generates DAV:href.

5. 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