CALDAV:calendar-multiget REPORT should not specify the calendar collection URL in the request body

RESOLVED FIXED in 1.0b1

Status

RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: bernard.desruisseaux, Assigned: browning)

Tracking

unspecified
1.0b1
Bug Flags:
blocking-calendar1.0 +

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/2.0.0.20 X-ORACLE-DEBUG=STATS (.NET CLR 3.5.30729)
Build Identifier: Lightning/1.0b1pre

The calendar collection URL should not be specified as a DAV:href element in the body of a CALDAV:calendar-multiget REPORT request.

Reproducible: Always

Steps to Reproduce:
1. Create CalDAV account
Actual Results:  
The Request-URI of the CALDAV:calendar-multiget REPORT request, that is, the calendar collection URL is erroneously specified in a DAV:href element in the request body.

Expected Results:  
The calendar collection URL should be omitted here.
(Reporter)

Comment 1

9 years ago
Prior to the CALDAV:calendar-multiget REPORT request, Lightning issues the following PROPFIND request on the calendar collection with Depth: 1

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

Lightning doesn't request the DAV:resourcetype property, as such it isn't clear how Lightning differentiate collections from calendar object resources in the PROPFIND response (i.e., the calendar collection targeted by the request as well as any regular non-calendar collection that could possibly exist in the calendar collection) and omit them from the subsequent CALDAV:calendar-multiget REPORT request.

This topic was recently discussed here:
http://blogs.sun.com/arnaudq/entry/subcollections_under_calendar_collections
(Assignee)

Comment 2

9 years ago
Created attachment 416745 [details] [diff] [review]
Ignore collections located inside the calendar collection

Patch adds the resourcetype check and omits collections from the multiget. Allows access to the test Oracle calendars. Did basic smoketests (create/modify/delete event) against Apple Bedework DAViCal Kerio Oracle Scalix SOGo Sun, all w/o mishap.
Assignee: nobody → browning
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #416745 - Flags: review?(philipp)
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: x86 → All
Comment on attachment 416745 [details] [diff] [review]
Ignore collections located inside the calendar collection

Looks fine. Given we might need a further rc1 build anyway, I'll check this in on all three branches.
Attachment #416745 - Flags: review?(philipp) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/3a201e2872ac>
and comm-191: 807677aad2c7 (default) / 362717be060d (1.0b1 relbranch)

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: blocking-calendar1.0+
Resolution: --- → FIXED
Whiteboard: [needed beta][no l10n impact]
Target Milestone: --- → 1.0
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.