Closed Bug 348891 Opened 14 years ago Closed 14 years ago

CalDAV provider fails to parse folded lines in Cosmo REPORT responses


(Calendar :: Provider: CalDAV, defect)

Not set


(Not tracked)



(Reporter: browning, Assigned: browning)



(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060614 Fedora/ Firefox/ pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060816 Calendar/0.3a2+

The calendar-data payload in Cosmo REPORT responses has lines that end in the string |
\n| instead of simply |\n|. CalDAV provider serializes this to |\n\n|, which is not a problem except in the case of folded lines: when libical parses the data it looks ahead one-and-only-one newline when checking for line folding.  So it "gets" the portion of a folded line before the first \n\n and errors on any continuations.

Reproducible: Always

Steps to Reproduce:
1. Create event on Cosmo CalDAV server with DESCRIPTION longer than say 80 characters.
2. Exit/restart Sunbird.
3. Examine event. Note missing data. If logging, not X-LIC-ERROR messages.

Actual Results:  
Sunbird effectively retrieves only the portion of folded lines before the first newline.

Expected Results:  
Complete event data should round-trip to the CalDAV server.

Given CalDAV para 9.5, it's hard to argue that Cosmo is out of spec here.
This could also be fixed in the serializer or in libical, I suppose. But it's specifically a CalDAV problem, so the CalDAV provider seems a good place to address it.
botched the comment in the patch and forgot to request review. Sheesh.
Attachment #234050 - Flags: first-review?(jminta)
Comment on attachment 234050 [details] [diff] [review]
replace \n\n in REPORT responses with \r\n

Is this a more generic problem?  I'm thinking of bug 324198.
I'm not sure I see a connection, other than in a general 'line-ends-are-a-pain' kind of way.

The current bug has to do with xmlserializer.serializeToString taking some peculiar, CalDAV-specific input and emitting non-rfc2445-compliant output, which is in turn used as input to the libical parser. If I'm understanding bug 324198 correctly, it's about libical doing something questionable with rfc2445-compliant input. In the case of the Cosmo-generated data mentioned here, I think libical is doing what it ought to. But maybe I'm missing something.
Attachment #234048 - Attachment is obsolete: true
Comment on attachment 234050 [details] [diff] [review]
replace \n\n in REPORT responses with \r\n

Ok, looks good to me, r=jminta.
Attachment #234050 - Flags: second-review?(dmose)
Attachment #234050 - Flags: first-review?(jminta)
Attachment #234050 - Flags: first-review+
Comment on attachment 234050 [details] [diff] [review]
replace \n\n in REPORT responses with \r\n

Nice catch; r=dmose.
Attachment #234050 - Flags: second-review?(dmose) → second-review+
Assignee: nobody → browning
Ever confirmed: true
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.