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.
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.