Open Bug 236212 Opened 20 years ago Updated 2 years ago

Bad attachment content type (mime)

Categories

(MailNews Core :: Attachments, defect)

defect

Tracking

(Not tracked)

People

(Reporter: os-bugzilla, Unassigned)

References

Details

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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.
Product: MailNews → Core
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.