Failing to parse iCal event when it contains NULL bytes
Categories
(Calendar :: Internal Components, defect)
Tracking
(Not tracked)
People
(Reporter: alex, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
I recently got a calendar invite looking suspicious but imports cleanly in a MS Exchange online environment.
The calender invitation is contained in a:
"Content-Type: text/calendar; charset="utf-8"; method=REQUEST
Content-Transfer-Encoding: base64"
And the problematic part are some "AAAAAAAAAAAAAAAAAAAAAAAAAA" runs resulting in the following when decoded (I guess the are NULL bytes according to base64 decoding):
...
TZID:Europe/Berlin
...
DTSTART;TZID=Europe/Berlin:20200318T130000
DTEND;TZID=Europe/Berlin:20200318T140000
UID:200:537
RECURRENCE-ID;TZID=Europe/Berlin:20200318T130000
...
Actual results:
Thunderbird shows the following error in the console:
console.warn: Lightning: Parsing failed for parts of the item (while this is considered to be a minor issue, we continue processing the item):
...
BEGIN:VTIMEZONE
TZID:Europe/BerlinBEGIN:STANDARD
DTSTART:16010101T020000
...
It then fails to display the invitation probably due to the malformed TZID above.
Expected results:
The NULL bytes should be processed as-is or replaced/removed. With the replacement placeholder the invitation validates on both https://icalendar.org/validator.html and https://mozilla-comm.github.io/ical.js/validator.html
|
||
Comment 1•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 2•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 3•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)
|
|
||
Comment 4•4 years ago
|
||
The severity of these bugs was changed, mistakenly, from normal to S3.
Because these bugs have a priority of --, indicating that they have not been previously triaged, these bugs should be changed to Severity of --.
|
||
Updated•4 years ago
|
Description
•