338415 - subscribing to non-UTF8 ICS file fails

Status: RESOLVED INVALID

(Calendar :: Internal Components, defect)

Description

[Dave Neary]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3


I tried to subscribe to the iCal calendar for GUADEC 2006 (June 24 - 30 2006, in Villanova i Geltru, near Barcelona), but the import failed.

The server isn't webDAV, but if I understand correctly, I should be able to subscribe read-only with just HTTP. I get two errors, one informing me that the calendar will be read-only (expected) and one saying there's a parse problem.

After downloading the file (attached), I get the error: 

Exception... "Component returned error code NS_ERROR_UNEXPECTED... calIcsImportExp[falls off the side of the screen] :: ics_importFromStream ::line 74": data = no

I hope that means more to you than it does to me.


Reproducible: Always

Steps to Reproduce:
Either:
1. New calendar -> Remote -> webDAV -> http://guadec.org/GUADEC2006/schedule/ical
or:
1. Save link above, rename to guadec.ics
2. Import into -> local calendar


Actual Results:  
Exception. Unexpected error.

Expected Results:  
Expected successful import and shiny GUADEC calendar

Comment 1

[Dave Neary]

Attachment: iCal file exhibiting problem

Comment 2

[Matthew (lilmatt) Willis]

Saving the file locally and attempting "Open Calendar File..." gives the following error:

"CAL_UTF8_DECODING_FAILED
An error occured while decoding an iCalendar (ics) file as UTF-8. Check that the file, including symbols and accented letters, is encoded using the UTF-8 character encoding."

The file has accented characters in it.

Dupe of bug 315672?

Comment 3

[Matthew (lilmatt) Willis]

Sorry for the bugspam. 
I just figured out how to check the file encoding in gedit.

This ics is encoded as ISO-8859-15

From RFC2445:
"4.1.4 Character Set


   There is not a property parameter to declare the character set used
   in a property value. The default character set for an iCalendar
   object is UTF-8 as defined in [RFC 2279].

   The "charset" Content-Type parameter can be used in MIME transports
   to specify any other IANA registered character set."


mwillis@stinkpad:~/Desktop$ curl --head http://guadec.org/GUADEC2006/schedule/ical
HTTP/1.1 302 Found
Date: Thu, 18 May 2006 12:19:35 GMT
Server: Apache/2.0.46 (Red Hat)
Accept-Ranges: bytes
X-Powered-By: PHP/4.3.2
Set-Cookie: PHPSESSID=9d54241007cdca66e9a2621a1026335e; expires=Sat, 10-Jun-2006 15:52:55 GMT; path=/
Location: http://www.google.com/calendar/ical/[e-mail]/public/basic
Connection: close
Content-Type: text/html; charset=utf-8

mwillis@stinkpad:~/Desktop$ curl --head http://www.google.com/calendar/ical/[e-mail]/public/basic
HTTP/1.1 200 OK
Content-Type: text/calendar
Cache-control: no-cache
Content-Length: 0
Date: Thu, 18 May 2006 12:19:43 GMT
Server: GFE/1.3

mwillis@stinkpad:~/Desktop$


Although we may want to be able to gracefully handle these situations, this doesn't exactly look like our problem here.

If Google is going to start sending non-UTF-8 .ics files around, according to the RFC then need to include a "charset" in "Content-Type"

Comment 4

[Matthew (lilmatt) Willis]

Attachment: the same iCal file, saved as UTF-8 using gedit. Opens cleanly

Comment 5

[Dave Neary]

Thanks. Funny, to get this file to open cleanly, I had to delete the calendars I'd created before before reimporting.

Closing invalid.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Reopening.  If we're explicitly told by the web-server what character encoding we should be using, I don't see any reason not to try and do the correct decoding.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Assuming we do decide to support this, we also need to decide what encoding we'll write the file out in.  I suspect the proper choice would be "whatever we were told when reading it".

Comment 8

[Dave Neary]

Perhaps I misunderstood comment #3, but it appeared to me that Matthew is saying that Google is publishing calendars in iso-8859-15, and setting the content-encoding to utf-8, which would make this a Google problem, not a Calendar problem.

Comment 9

[Matthew (lilmatt) Willis]

(In reply to comment #8)
> ...Matthew is saying that Google is publishing calendars in iso-8859-15,
> and setting the content-encoding to utf-8, which would make this a Google
> problem, not a Calendar problem.

To clarify:
This calendar specifically seems to be encoded using ISO-8859-15.
Google's web server did not provide any encoding information. In the absence of such information, RFC2445 says we should treat it as UTF-8, which we did, which was the source of the errors originally seen. 

So from my interpretation, Google's server should be providing the alternate encoding, and if we're given an alternate encoding, we should be respecting that upon import.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

Ah, I did indeed read over this bug too quickly.  Sorry about that.  Re-resolving.

Comment 11

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!