A user gets this when importing a medium-sized .ics file from Sunbird:
2005-04-26 11:48:21,625
http://server:7080/persons/jim/calendar.ics
Traceback (most recent call last):
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 138, in publish
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\app\publication\http.py",
line 43, in callObject
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 113, in mapply
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 119, in debug_call
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\app\http\put.py",
line 112, in PUT
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\app\cal.py",
line 140, in write
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 314, in read_icalendar
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 539, in iterEvents
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 1068, in validate
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 1099, in _getType
AssertionError
Unfortunately, looking at that leaves me none the
wiser!
Most of the blocks in the log (presumably
corresponding to the several attempts I made to
publish the calendar files) look exactly the same
(except the time); however, there is a 'variation upon
the theme':
2005-04-26 12:12:07,000
http://server:7080/persons/julian/calendar.ics
Traceback (most recent call last):
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 138, in publish
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\app\publication\http.py",
line 43, in callObject
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 113, in mapply
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\publisher\publish.py",
line 119, in debug_call
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\Zope3\src\zope\app\http\put.py",
line 112, in PUT
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\app\cal.py",
line 140, in write
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 314, in read_icalendar
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 521, in iterEvents
File "C:\Shared
Files\Downloads\Diary\schoolbell-1.0\src\schoolbell\calendar\icalendar.py",
line 487, in _iterRow
UnicodeDecodeError: 'utf8' codec can't decode byte
0xa3 in position 21: unexpected code byte
There are two distinct problems here.
One problem is the assertion error. It is a bug in our iCalendar parser. It
happens when there is a recurring event with more than one exception date. I've
marked the location of the bug with an XXX comment that includes a proposed fix;
it remains to write a regression test for this bug and apply the fix. (See the
checkin for revision 3533).
Another problem is character-set related. The iCalendar spec (RFC 2445) says
that the default charset of iCalendar files is UTF-8, but it can be overriden
with MIME Content-Type headers. The Zope 3 infrastructure that implements HTTP
PUT does not pass the Content-Type request header to our code and we always
assume the data is in UTF-8. It is possible that Sunbird sends data in some
other encoding and specifies it in the header.
Fixing this other problem might require some changes in Zope 3.