Mime parameters are stripped off when setting contentType of nsMsgAttachment

RESOLVED FIXED in mozilla1.2alpha


MailNews Core
16 years ago
10 years ago


(Reporter: ajbu, Assigned: Jean-Francois Ducarroz)


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: Have fix)


(1 attachment, 1 obsolete attachment)



16 years ago
build 2002080208
When setting the contentType for an attachment, the mime-parameters are 
stripped off. Mime parameters are part of the mime specification, and are 
needed for inviting over mail using Mozilla Calendar.
Example contenttype of a Calendar meeting request according to the iCalendar 
 Content-Type:text/calendar; method=request; charset=UTF-8;

Looking at nsMsgAttachment.cpp#121, the paramaters are stripped out in 
SetContentType, I don't understand the 'need' for cleanup here. This removal 
of parameters will block using Calendar over email.

121 NS_IMETHODIMP nsMsgAttachment::SetContentType(const char * aContentType)
122 {
123   mContentType = aContentType;
124   /* a full content type could also contains parameters but we need to
125      keep only the content type alone. Therefore we need to cleanup it.
126   */
127   PRInt32 offset = mContentType.FindChar(';');
128   if (offset >= 0)
129     mContentType.Truncate(offset);
131   return NS_OK;
132 }

Comment 1

16 years ago
nsIMsgAttachment are used only by message composition (new, forward, template
and draft). This is not used when displaying a received message!

Reporter, can you explain what is the real problem?

Comment 2

16 years ago
Problem is about sending a message, not displaying one.
Mozilla Calendar *sends* a message with an attachment of text/calendar type 
that needs the method parameter mentioned.

Code that sets the contenttype:
s#192 (needed parameter removed here because they didn't work)
It adds the calendar event as an attachment to the message and calls 
nsIMsgComposeService.OpenComposeWindowWithParams for sending.

This system of exchanging appointments is specified by RFC 2445

Comment 3

16 years ago
For correctness: I mean RFC 2447, iCalendar Message-Based Interoperability 
Protoco (iMIP) (ftp://ftp.isi.edu/in-notes/rfc2447.txt)


16 years ago
QA Contact: gayatri → yulian

Comment 4

16 years ago
Thanks for the clarification. I'll look into it...
Target Milestone: --- → mozilla1.2alpha

Comment 5

16 years ago
I have a fix which I haven't tested yet. Bassically, I added a new attribute to
nsIMsgAttachment to handle content-type extra params. You will need to add the
following line in calendarMail.js:

  nsIMsgAttachment.contentType = "text/calendar";
  nsIMsgAttachment.contentTypeParam = "method=request";

The charset will be generated during the send. Let me know if that cause a
problem too.

Ajbu, would be nice if you could give a try to this patch...
Whiteboard: Have fix

Comment 6

16 years ago
Created attachment 95154 [details] [diff] [review]
Proposed fix, v1 (not tested)

Comment 7

16 years ago
contentTypeParam seems to work fine. Send doesn't set a charset for 
attachments, the generated header for the attachement is:

Content-Type: text/calendar; method=REQUEST;
 name="iCal Event"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="iCal Event"

Comment 8

16 years ago
no charset has been generated probably because the data is ISO-8859-1 which is
the default. Does the fact the charset is "missing" cause any trouble? Are you
able to  open and view correctly the calendar attachment?

Comment 9

16 years ago
Actualy, I use hebrew, copied from: http://www.columbia.edu/kermit/utf8.html
when using hebrew in both the messagebody (text/plain) and the attachment, the 
messagebody is readable, but the text/calendar attachment also shown in mail 
is garbage.
Sending a text attachment doesn't seem to detect the charset used and assumes 

Note that the calendar event is saved to the tempdir and then attached using 
the url property. I copied some text from the utf8.html page for testing.
Also note that nsIMsgAttachment.url is a string, so won't work when using a 
url to a directory with a unicode name?

Comment 10

16 years ago
There are other bugs about not setting the character set, like bug 71551.
It would be logical if nsMsgAttachment has a property to set the charset like 
nsIMsgCompFields: 74   attribute string  characterSet;

Offcourse the new contentTypeParam can be used for that, but characterSet 
would be more consistent.

Comment 11

16 years ago
I'll add a charset attribute to the attachment structure..., that will prepare
the ground for bug 71551.

Comment 12

16 years ago
Created attachment 95277 [details] [diff] [review]
Proposed fix, v2

I added the support for a charset attribute as well a content-type param
(already  in previous patch) in nsIMsgAttachment.
Attachment #95154 - Attachment is obsolete: true

Comment 13

16 years ago
Ajbu, can you test the new patch to make sure it fit your needs. Just add the
following in your code:

  nsIMsgAttachment.contentType = "text/calendar";
  nsIMsgAttachment.contentTypeParam = "method=request";
  nsIMsgAttachment.charset = "<whatever you charset is>";


Comment 14

16 years ago
Setting contentTypeParam and charset works and generates the desired content-


16 years ago
Blocks: 71551

Comment 15

16 years ago
Comment on attachment 95277 [details] [diff] [review]
Proposed fix, v2

We should probably rewrite or change the PUSH_STRING stuff sometime later.
Looks good to me. This will help with the internationalisation problem of
handling attachemnts of text files in japanese because now we can pass the
charsets from the front.
Attachment #95277 - Flags: review+

Comment 16

16 years ago
Comment on attachment 95277 [details] [diff] [review]
Proposed fix, v2

Attachment #95277 - Flags: superreview+

Comment 17

16 years ago
Fixed in the trunk
Last Resolved: 16 years ago
Resolution: --- → FIXED
QA Contact: yulian → stephend
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.