1579427 - When using PUT to create new calendar event Location header is ignored

Status: UNCONFIRMED

(Calendar :: Provider: CalDAV, defect)

Description

[cristian.draghici]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

I created a new calendar, on the network, using a CalDAV account.
I then attempt to create a new event.

Actual results:

The calendar becomes disabled.
The error console shows "CalDAV: Get failed: multiget error".

This is likely because our CalDAV server uses a Location header when answering 201 Created. This is because we do not save the calendar item at the location required by the client in the PUT URL but rather in a custom location announced via the Location header.

This can be seen in the CalDAV trace:
INPUT >> PUT Calendar/Calendar/4346bebc-8255-3542-aeec-c58d100e4cfd.ics
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 719
Content-Type: text/calendar
Host: ccd.axigen.com
If-none-match: *
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Lightning/6.2.9
BEGIN:VCALENDAR
[..]
OUTPUT <<
HTTP Code: Created 201
Location: /Calendar/Calendar/Calendar_240_534_29.ics

Later on Thunderbird still uses its own URL and its multiget request fails:
INPUT >> REPORT Calendar/SharedFolders/usera/cal10/
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 277
Content-Type: application/soap+xml; text/xml
Depth: 1
Host: 172.25.0.9
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.0 Lightning/68.0
<?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>/Calendar/SharedFolders/usera/cal10/23c7095c-dda9-4acb-a6a8-86446dd9d146.ics</D:href></C:calendar-multiget>

Expected results:

Lightning should respect the Location header that accompanies 201 Created responses.

Comment 1

[cristian.draghici]

Note: Lighting version 40something used to work with our CalDAV implementation.(In reply to cristian.draghici from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

I created a new calendar, on the network, using a CalDAV account.
I then attempt to create a new event.

Actual results:

The calendar becomes disabled.
The error console shows "CalDAV: Get failed: multiget error".

This is likely because our CalDAV server uses a Location header when answering 201 Created. This is because we do not save the calendar item at the location required by the client in the PUT URL but rather in a custom location announced via the Location header.

This can be seen in the CalDAV trace:
INPUT >> PUT Calendar/Calendar/4346bebc-8255-3542-aeec-c58d100e4cfd.ics
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 719
Content-Type: text/calendar
Host: xyz.axigen.com
If-none-match: *
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Lightning/6.2.9
BEGIN:VCALENDAR
[..]
OUTPUT <<
HTTP Code: Created 201
Location: /Calendar/Calendar/Calendar_240_534_29.ics

Later on Thunderbird still uses its own URL and its multiget request fails:
INPUT >> REPORT Calendar/Calendar/
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 260
Content-Type: application/soap+xml; text/xml
Depth: 1
Host: xyz.axigen.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Lightning/6.2.9
<?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>/Calendar/Calendar/4346bebc-8255-3542-aeec-c58d100e4cfd.ics</D:href></C:calendar-multiget>

Expected results:

Lightning should respect the Location header that accompanies 201 Created responses.

Comment 2

[Stefan Sitter [:ssitter]]

Does the current Thunderbird 68 release with Lightning 7.0 show the same or different behavior?

Comment 3

[cristian.draghici]

For some reason Thunderbird was not updating to 68 by itself.
I've upgraded manually to Thunderbird 68.0 but the new Lightning version is listed as 68.0, not 7.0 as you suggest. I'm on a Mac if that makes any difference.

With this version:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.0 Lightning/68.0

I see the same behaviour:

INPUT >> PUT Calendar/Calendar/7171b6fc-5e40-de4d-97fa-0cc1727daffb.ics
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 719
Content-Type: text/calendar
Host: xyz.axigen.com
If-none-match: *
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.0 Lightning/68.0
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
[..]
END:VCALENDAR

OUTPUT <<
Code: 201
Location: /Calendar/Calendar/Calendar_240_534_32.ics
Content-Location: /Calendar/Calendar/Calendar_240_534_32.ics

INPUT >> REPORT Calendar/Calendar/
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Content-Length: 260
Content-Type: application/soap+xml; text/xml
Depth: 1
Host: xyz.axigen.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.0 Lightning/68.0
<?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>/Calendar/Calendar/7171b6fc-5e40-de4d-97fa-0cc1727daffb.ics</D:href></C:calendar-multiget>

Comment 4

[cristian.draghici]

The patch below solves the issue I've described.
It is written against Thunderbird 69.0b4 (with the corresponding Lightning version).
What it does is allow a server to override the locationPath for a cached item by returning a Location header in a 201 Created response.

It does require review as this is my first time messing with the XPI system and my javascript knowledge is lacking.
But I think the principle behind it is correct and as long as the Lightning event cache model allows a locationPath not to be derived from the event UID (which it seems it does) I don't see why it should break any existing functionality.

MacBook-Pro-2:light diciu$ diff -u /tmp/tot/components/calDavCalendar.js  components/calDavCalendar.js
--- /tmp/tot/components/calDavCalendar.js	2010-01-01 00:00:00.000000000 +0200
+++ components/calDavCalendar.js	2019-09-10 08:20:58.000000000 +0300
@@ -683,8 +683,18 @@
                     let targetParts = request.URI.pathQueryRef.split("/");
                     targetParts.splice(0, uriComponentParts - 1);
 
-                    self.mItemInfoCache[parentItem.id] = { locationPath: targetParts.join("/") };
-                    // TODO: onOpComplete adds the item to the cache, probably after getUpdatedItem!
+                    if(request.getResponseHeader("Location")) {
+                        let locationUriComponentParts = request.getResponseHeader("Location").replace(/\/{2,}/g, "/").split("/").length;
+                        let locationTargetParts = request.getResponseHeader("Location").split("/");
+                        locationTargetParts.splice(0, locationUriComponentParts - 1);
+                        self.mItemInfoCache[parentItem.id] = { locationPath: locationTargetParts.join("/") };
+                    }
+                    else {
+                        self.mItemInfoCache[parentItem.id] = { locationPath: targetParts.join("/") };
+                        // TODO: onOpComplete adds the item to the cache, probably after getUpdatedItem!
+                    }