GNOME Bugzilla – Bug 585851
Invalid calendar attachments due to truncation
Last modified: 2009-08-12 11:26:48 UTC
Please describe the problem: When trying to debug bug #569321 it seems that calendar invites are truncated. This may or may not be related to the encoding problems in that bug. The truncation caused evolution to say (Translated from swedish): The message claims to contain a calendar, but the calendar is not a valid iCalendar. Looking at both raw messages I see the following importand difference:' A working message I have ends with: CLASS:PUBLIC BEGIN:VALARM X-EVOLUTION-ALARM-UID:20090615T112310Z-26147-1000-25374-10@saphira ACTION:DISPLAY TRIGGER;VALUE=DURATION;RELATED=START:PT0S END:VALARM END:VEVENT END:VCALE --=-jjvNiykRJ5F9irzFAFKj-- Non working ends with: ORGANIZER;CN=Daniel Wik:MAILTO:DWik@vizrt.com PRIORITY:1 CLASS:PUBLIC BEGIN:VALARM X-EVOLUTION-ALARM-UID:20090615T112152Z-26147-1000-25374-4@saphira ACTION:DISPLAY TRIGGER;VALUE=DURATION;RELATED=START:PT0S END:VALARM E --=-0LXmfX2AaDdn+LIkx3SS-- So I guess the first one works since the last END part is ok, and the parser really doesn't care that teh VCALENDAR part is truncated. However the non working part is even more truncated causing the END part of VEVENT to be truncated. So I guess that there are some general bug in multipart attachments or something. I'm thinking if it may be something related to the encoding causing some lenght calcualtion go wrong that does some assumption like one char one byte. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I don't know if it is interesting at all, but in the imap versions of the mail, the attachments are base64 encoded. Thought it may be interesting if it should be some problem in the decoding.
Created attachment 136841 [details] [review] Fix to use strlen and not g_utf8_strlen g_utf8_strlen counts the number of characters in the string, but in this case we want the number of bytes. So strlen should be used even if the string is in some utf8:ish encoding.
For html mail that are handled like multipart attachments I can see the last > character is missing. Removing the -1 from the len in this part in camel-mapi-folder.c solved that, but I guess someone put it there for a reason.... /*NOTE : Last byte null mess up CRLF*. Probably needs a fix in e*fetch_items. */ camel_mime_part_set_content (part, (const char *) body->value->data, body->value->len -1, type );
What is the status of getting this fix in? //Mattias
Please commit the patch in #2 and #3. Thanks.
Committed patch in comment#2 . Thanks.
(In reply to comment #3) > For html mail that are handled like multipart attachments I can see the last > > character is missing. > Removing the -1 from the len in this part in camel-mapi-folder.c solved that, > but I guess someone put it there for a reason.... > /*NOTE : Last byte null mess up CRLF*. Probably needs a fix in e*fetch_items. > */ > camel_mime_part_set_content (part, (const char *) > body->value->data, body->value->len -1, type ); > I'm a little bit confused here, because that '-1' was introduced with respect to bug #561792 . But now it doesn't seem to be happening. Committing to master. Closing bug as fixed. Thanks.