Invalid folding in generated .ics file! Using LF instead of CRLF.

RESOLVED FIXED

Status

RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: ruchbah, Assigned: gray)

Tracking

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Trieing to parse a ics-file I found, that incorrect folding occurs in a long
'DESCRIPTION' elements.

Lines are folded using LF+Whitesapce. This is not correct according to RFC2445,
which specifies CR+LF+Whitespace as folding sequence.

This is kind of strange, because all other lines are folded correct.
I found this only in folded 'DESCRIPTION'-elements.

Reproducible: Always

Steps to Reproduce:
1. Create a VENVENT, using a long (> 75 chars) description.
2. Open ICS-file, using a Hex editor.
3.
Actual Results:  
You'll se folding, using 200A20 sequences within descriptions, instead of
0D0A20, which sould be.

Expected Results:  
Produce folding sequences using CR-LF-Whitespace.
(Reporter)

Comment 1

14 years ago
Ok, after some source research, I would pin the problem to 'icalproperty.c',
method 'fold_property_line()'.

I found following preprocessor directive:

#ifdef ICAL_UNIX_NEWLINE
    char newline[] = "\n";
#else
    char newline[] = "\r\n";
#endif

This may be a good idea for writing textfiles on PC or UNIX systems, but as I
read the RFC2445, newline is always defined as CRLF sequence, so this code is
obsolete.

Recompiling without 'ICAL_UNIX_NEWLINE' should solve the problem.

Regards

Markus
(Reporter)

Updated

13 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Component: libical → Internal Components
The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!
QA Contact: libical → base
You need to log in before you can comment on or make changes to this bug.