User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Small problem with an attachement: I just tried to send a php source file and it got attached with a text/html content type. So doing, some email readers choise this "html" content as the main email content and prevent the receiver to read the real email content. Reproducible: Always Steps to Reproduce: 1. Take a simple .php file with a content like "<?php echo 'test' ?>" 2. Create a new email 3. Attach the php file 4. Send/Save this email 5. Check the source of the generated email. Actual Results: Content-Type: text/html; Expected Results: Some possibilities: Content-Type: application/x-httpd-php; Content-Type: application/octet-stream; An other idea is to let it working as is, but add some possibility to change the type of the attachement. If you take a look at Outlook generated mime-type for a similar case, it is: Content-Type: application/octet-stream; that is generated. Same problem occurs of course using Thunderbird.
Mozilla get's text/html either from the windows registry or from edit\preferences\Navigator\Helper apps
remove comment#1, Mozilla seems to use the unkown content-decoder (is that right biesi ?)
I just checked my windows registry, and php files do not have any content-type associated with. I got the problem both with mozilla and thunderbird, where no mime-type is associated with php files. I will check for this problem on my linux station tomorrow...
(In reply to comment #2) > remove comment#1, Mozilla seems to use the unkown content-decoder (is that right > biesi ?) doubtful... but I don't know how mailnews does this determination. most likely seems to be though that it uses the mimeservice to guess from the file...
Just tested on my linux version -> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031207 Same problem. (a 'file' command on this file reports: PHP script text ) So, it seems for me a mozilla problem.
*** Bug 239849 has been marked as a duplicate of this bug. ***
Setting platform to ALL/ALL since symptom is seen under Linux. Assuming the way to determine the correct type is found, shouldn't the default type be text/php ? I tried setting up my Windows registry with CLSID\.php pointing to CLSID\MIME\DataBase\Content-Type\text/php and vice-versa, but Mozilla ignored that. I also set up the Helper Apps in Mozilla with a text/php type associated with .php; that was also ignored on adding the attachment.
OS: Windows 2000 → All
Hardware: PC → All
Well, this isn't a big deal. Since they are both text. This is just association. Not a corruption issue (it's not like we are sending binary as ASCII, or vice versa). Here's what I see in mail that I sent with a sample php script (note it was sent from a computer with the content-type set to PHP in the registry): Content-Type: text/html; name="test1.php" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="test1.php" <?php // create handle for new PDF document $pdf = pdf_new(); // open a file pdf_open_file($pdf, "philosophy.pdf"); // start a new page (A4) pdf_begin_page($pdf, 595, 842); // get and use a font object $arial = pdf_findfont($pdf, "Arial", "host", 1); pdf_setfont($pdf, $arial, 10); // print text pdf_show_xy($pdf, "There are more things in heaven and earth, Horatio,",50, 750); pdf_show_xy($pdf, "than are dreamt of in your philosophy", 50,730); // end page pdf_end_page($pdf); // close and save file pdf_close($pdf); ?> Either way, not a huge deal, but yes, it should most likely be text/php.
(In reply to comment #7) > I tried setting up my Windows registry with CLSID\.php pointing to > CLSID\MIME\DataBase\Content-Type\text/php and vice-versa, but Mozilla ignored > that. I also set up the Helper Apps in Mozilla with a text/php type associated > with .php; that was also ignored on adding the attachment. HKEY_CLASSES_ROOT\.<extention> is usual key used for content type determination by Mozilla on MS Windows. Did you try HKEY_CLASSES_ROOT\.php? (Name = Content Type , data = application/x-httpd-php; ) When I defined it for ".dat", Mozilla on Win-2K generated next headers. (xxx.dat content is Shift_JIS text) > Content-Type: application/x-httpd-php; name="xxx.dat" > Content-Transfer-Encoding: base64 > Content-Disposition: inline; filename="xxx.dat"
(In reply to comment #7) > I also set up the Helper Apps in Mozilla with a text/php type associated > with .php; that was also ignored on adding the attachment. Mike Cowperthwaite, really? Didn't you enter ".php"(with dot) in Extention field of Helper Applications? Preceding "dot" should be omitted when Helper Applications. See my comment of Bug 241821 Comment 5 .
(In reply to comment #10) > Mike Cowperthwaite, really? > Didn't you enter ".php"(with dot) in Extention field of Helper Applications? > Preceding "dot" should be omitted when Helper Applications. Yes, you are correct -- I did enter it with the dot. After changing it to remove the dot, attaching the .PHP file caused it be generated as a text/php attachment. I then removed the Windows registry items I'd added as a test, and restarted Mozilla -- again, attaching the file caused it be text/php. So, that's the workaround for those of you attaching .php files -- specify the MIME type you want (e.g. text/php) in the Helper Apps, and assign it the "php" extension. Thanks, WADA.
(In reply to comment #11) > Yes, you are correct -- I did enter it with the dot. After changing it to > remove the dot, attaching the .PHP file caused it be generated as a text/php can you file a bug about that? it should work both with and without the dot. component file handling in browser product, please.
(In reply to comment #12) > (In reply to comment #11) > > Yes, you are correct -- I did enter it with the dot. After changing it to > > remove the dot, attaching the .PHP file caused it be generated as a text/php > > can you file a bug about that? it should work both with and without the dot. > component file handling in browser product, please. Didn't have to file one; bug 170090 was just waiting for confirmation.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Summary: Bad attachement content type (mime) → Bad attachment content type (mime)
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → attachments
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.