540398 - On accepting an invitation through CalDAV, PUT is done on a bogus resource URL

Reporter

Description

•

15 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

Lightning 1.0b1 with scheduling enabled against Sun Calendar Server 7u1.

Attendee has an event in his calendar and has a corresponding itip REQUEST in his calendar-inbox. The event is correctly shown as requesting a response, when opening it. On accepting, an "Event Modified" error is shown.

From what I can see, the PUT in the calendar corresponding to the reply is using the calendar url, but the last segment corresponds to the itip REQUEST url segment:

The Calendar Resource fetched by the client is under:
/davserver/dav/home/arnaudq/calendar/-1263808349743-2-.ics
The corresponding iTIP REQUEST (also fetched by the client) is under:
/davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/REQUEST-1263808349653-1-.ics

The PUT is done on:
/davserver/dav/home/arnaudq/calendar/REQUEST-1263808349653-1-.ics

which is a mix of the calendar url: /davserver/dav/home/arnaudq/calendar/
with the iTIP REQUEST last segment: REQUEST-1263808349653-1-.ics

when it should be done on -1263808349743-2-.ics

Here is the detailed exchange:

1) calendar sync with the server:

PROPFIND /davserver/dav/home/arnaudq/calendar/ HTTP/1.1
user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
content-type: text/xml; charset=utf-8
depth: 1

<?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontenttype/>
    <D:resourcetype/>
    <D:getetag/>
  </D:prop>
</D:propfind>

207 
Content-Type: application/xml; charset="utf-8"
DAV: calendar-auto-schedule

<?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:M="urn:ietf:params:xml:ns:carddav">
<D:response>
<D:href>/davserver/dav/home/arnaudq/calendar/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><C:calendar/><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/davserver/dav/home/arnaudq/calendar/-1263808349743-2-.ics</D:href>
<D:propstat>
<D:prop>
<D:getcontenttype>text/calendar</D:getcontenttype>
<D:resourcetype></D:resourcetype>
<D:getetag>"1263808349000.1"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

REPORT /davserver/dav/home/arnaudq/calendar/ HTTP/1.1
depth: 1

<?xml version="1.0" encoding="UTF-8"?>
<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:getetag/>
    <calendar-data/>
  </D:prop>
  <D:href>/davserver/dav/home/arnaudq/calendar/-1263808349743-2-.ics</D:href>
</calendar-multiget>

207 
Content-Type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:M="urn:ietf:params:xml:ns:carddav">
<D:response>
<D:response>
<D:href>/davserver/dav/home/arnaudq/calendar/-1263808349743-2-.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"1263808349000.1"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sun Microsystems/CS 7u1-1.04//EN
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T020000
TZNAME:GMT+02:00
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T030000
TZNAME:GMT+01:00
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:FC8D06A4-2F20-4229-B658-DCB9F1E39182
DTEND;TZID=Europe/Paris:20100122T090000
ATTENDEE;CN=ciny;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:ciny.joy@sun.
 com
ATTENDEE;CN=arnaudq@ics-s8.red.iplanet.com;CUTYPE=INDIVIDUAL;EMAIL=arnaud
 q@ics-s8.red.iplanet.com;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP
 =TRUE:mailto:arnaudq@ics-s8.red.iplanet.com
SUMMARY:Event 43
DTSTART;TZID=Europe/Paris:20100122T071500
DTSTAMP:20100118T095202Z
CREATED:20100118T095229Z
LAST-MODIFIED:20100118T095229Z
ORGANIZER;CN=ciny:mailto:ciny.joy@sun.com
SEQUENCE:3
TRANSP:TRANSPARENT
X-APPLE-NEEDS-REPLY:TRUE
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

Sync on the scheduling inbox:
PROPFIND /davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/ HTTP/1.1
depth: 1

<?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontenttype/>
    <D:resourcetype/>
    <D:getetag/>
  </D:prop>
</D:propfind>

207 
Content-Type: application/xml; charset="utf-8"
DAV: calendar-auto-schedule

<?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:M="urn:ietf:params:xml:ns:carddav">
<D:response>
<D:href>/davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><C:schedule-inbox/><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:getcontenttype/>
<D:getetag/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/REQUEST-1263808349653-1-.ics</D:href>
<D:propstat>
<D:prop>
<D:getcontenttype>text/calendar</D:getcontenttype>
<D:resourcetype></D:resourcetype>
<D:getetag>"1263808349000.1"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

REPORT /davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/ HTTP/1.1
depth: 1

<?xml version="1.0" encoding="UTF-8"?>
<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:getetag/>
    <calendar-data/>
  </D:prop>
  <D:href>/davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/REQUEST-1263808349653-1-.ics</D:href>
</calendar-multiget>

207 
Content-Type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="UTF-8"?><D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:M="urn:ietf:params:xml:ns:carddav">
<D:response>
<D:href>/davserver/dav/home/Arnaud.quillaud@sun.com/calendar-inbox/REQUEST-1263808349653-1-.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"1263808349000.1"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sun Microsystems/CS 7u1-1.04//EN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T020000
TZNAME:GMT+02:00
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T030000
TZNAME:GMT+01:00
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:FC8D06A4-2F20-4229-B658-DCB9F1E39182
DTEND;TZID=Europe/Paris:20100122T090000
ATTENDEE;CN=ciny;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:ciny.joy@sun.
 com
ATTENDEE;CN=arnaudq@ics-s8.red.iplanet.com;CUTYPE=INDIVIDUAL;EMAIL=arnaud
 q@ics-s8.red.iplanet.com;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP
 =TRUE:mailto:arnaudq@ics-s8.red.iplanet.com
SUMMARY:Event 43
DTSTART;TZID=Europe/Paris:20100122T071500
DTSTAMP:20100118T095202Z
ORGANIZER;CN=ciny:mailto:ciny.joy@sun.com
SEQUENCE:3
X-SUN-TRIGGER-TYPE:ORG_RESCHEDULE
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

PUT /davserver/dav/home/arnaudq/calendar/REQUEST-1263808349653-1-.ics HTTP/1.1
content-length: 1048
content-type: text/calendar; charset=utf-8
if-match: "1263808349000.1"


412 if-match or if-unmodified condition failed

Reproducible: Always

Arnaud Quillaud

Reporter

Updated

•

15 years ago

Version: unspecified → Lightning 1.0b1

mguessan

Comment 1

•

14 years ago

Confirmed with the same client (Thunderbird 3/Lightning 1.0b1) and a different Caldav server (DavMail with an Exchange 2003 backend).

calendar url is: /users/user@company.com/calendar
inbox url is: /users/user@company.com/inbox
shedule enabled: calendar.caldav.sched.enabled=true
Caldav server supports schedule, but not auto-schedule

Expected behaviour on inbox event through Lightning:
- create a new event in calendar
- notify organizer
- delete inbox event

This is working fine under Thunderbird 2/Lightning 0.9, but Lightning 1.0b1 tries to update a non existing event under /calendar through caldav_doModifyItem, with the etag of the inbox event => 412 precondition failed

Martin Schröder [:mschroeder]

Updated

•

14 years ago

Whiteboard: qawanted

mguessan

Comment 2

•

14 years ago

Think I found the root cause in calDavCalendar.js, function  caldav_doModifyItem:
Lightning tries to create the accepted event in user calendar based on inbox event content, but with the inbox event etag.

=> a create request with an If-Match header will always fail.

A simple way to fix this is to avoid setting the If-Match header if wasInboxItem is true.

Philipp Kewisch [:Fallen] [:📆][:🧩]

Comment 3

•

14 years ago

Simon, can you confirm this?

Arnaud Quillaud

Reporter

Comment 4

•

14 years ago

When talking to an autoschedule server, one should not set the calendar.caldav.sched.enabled=true option.
Removing it fixed the issue.

To mguessan, feel free to reopen it if you feel that support for the old scheduling draft is important.

Status: UNCONFIRMED → RESOLVED

Closed: 14 years ago

Resolution: --- → INVALID

mguessan

Comment 5

•

14 years ago

Well, I do feel it's important: with DavMail I do not support the full server side handling defined in autoschedule (DavMail is just a gateway between the Caldav client and Exchange) but simple schedule is available.

And the patch is really simple:
-        if (!aIgnoreEtag) {
+        if (!wasInboxItem && !aIgnoreEtag) {

However, I can just add comment here, I am not allowed to reopen this entry.

Simon Vaillancourt

Comment 6

•

14 years ago

The bug is actually that the table mItemInfoCache indexes items by their UID and that table contains the ETAG (mItemInfoCache[item].etag), so if a meeting with UID:123 has also itip messages in the inbox, the etag can end up being one of the itip message. The same things goes for locationPath, fixing this in a proper way does not seem trival. 

The hack suggested by mguessan would probably work but it would also introduce the possibility of overwriting changes made by the server or another client without notifying the user. 

The whole calendar-schedule feature will hopefully be gone eventually since it is based on a deprecated draft(and it complicates the provider code so much), most CalDAV server developers I know have or are already working on a auto-schedule implementation, I hope DavMail will be in that list soon too :).

mguessan

Comment 7

•

14 years ago

Draft 4 (calendar-schedule) is working fine with both Lightning 0.9 and Apple iCal, but Lightning 1.0 is not compatible with Caldav servers at this level.

The new Draft 8 defining calendar-auto-schedule is far more complex, as it mixes server side with client side handling where Draft 4 was straightforward.
They even had to define a new HTTP header (If-Schedule-Tag-Match) to handle update conflicts !

Is there any Caldav server actually supporting this ?
 
Anyway, I had to disable schedule-inbox support in DavMail 3.8 with Lightning 1.* to avoid the errors described in this bugreport. Users can still receive meeting requests over IMAP.

I also had to implement a workaround for non url encoded hrefs sent by Lightning in REPORT requests, but this is another bug.

Arnaud Quillaud

Reporter

Comment 8

•

14 years ago

Most server implementations do support the new model.
While it definitely makes things more complicated on the server side, it is now somehow easier to build a scheduling enabled client. That was the main reason behind the change: implementing a calendar client is hard and there is still a lack of CalDAV enabled ones.

mguessan

Comment 9

•

14 years ago

Just another question: which draft is supported by Lightning 1 ?

Apparently, there is no reference to If-Schedule-Tag-Match in Lightning code.

Mohit Kanwal [:redDragon]

Comment 10

•

10 years ago

Just to quip in,
Schedule-Tag implementation is part of Google Summer of Code 2014 which aims to bring the RFC6638 to Lightning. Check out bug 1015717 for details.

Martin Schröder [:mschroeder]

Updated

•

10 years ago

Whiteboard: qawanted

Bugzilla

Quick Search

On accepting an invitation through CalDAV, PUT is done on a bogus resource URL

Categories

(Calendar :: Provider: CalDAV, defect)

Tracking

(Not tracked)

People

(Reporter: quillaud, Unassigned)

References

Details

Crash Data

Security

(public)

User Story

Description

Updated

Comment 1

Updated

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Comment 10

Updated