Closed
Bug 316143
Opened 20 years ago
Closed 19 years ago
upload of pdf send wrong mime type
Categories
(Firefox :: File Handling, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 373621
People
(Reporter: kma, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
When uploading pdf files from a web form firefox set the mime type as application/unknown where it should be application/pdf.
I have only tested with enctype="multipart/form-data" method="post".
Reproducible: Always
Steps to Reproduce:
1. save the php script I include with "Additional info" on a server
2. visit the page and upload a pdf
3. the mime type recieved by server is printed along with a few other data
Actual Results:
[type] => application/unknown
Expected Results:
[type] => application/pdf
The mime type is set correctly in the old version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
I use following small php script to view and reproduce the error:
--- BEGIN PHP ---
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><title>post file check</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
</head>
<body>
<form enctype="multipart/form-data" action="<?php print $_SERVER['PHP_SELF']; ?>" method="post">
<input type="file" name="uploadfile" />
<input type="submit" name="upload" value="Upload" />
</form>
<pre>
<?php
if (isset($_POST['upload']))
print_r($_FILES['uploadfile']);
?>
</pre>
</body>
</html>
--- END PHP ---
Related to bug 279619?
You're right. I followed the tip there and found following three pdf related entries in my "C:\Documents and Settings\?\Application Data\Mozilla\Firefox\Profiles\?.default\mimeTypes.rdf":
<RDF:Description RDF:about="urn:mimetype:application/pdf"
NC:fileExtensions="pdf"
NC:description=""
NC:value="application/pdf"
NC:editable="true">
<NC:handlerProp RDF:resource="urn:mimetype:handler:application/pdf"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:application/"
NC:value="application/"
NC:editable="true"
NC:fileExtensions="pdf"
NC:description="Adobe Acrobat 7.0 Document">
<NC:handlerProp RDF:resource="urn:mimetype:handler:application/"/>
</RDF:Description>
.
.
.
<RDF:Description RDF:about="urn:mimetype:application/unknown"
NC:value="application/unknown"
NC:editable="true"
NC:fileExtensions="pdf"
NC:description="Adobe Acrobat 7.0 Document">
<NC:handlerProp RDF:resource="urn:mimetype:handler:application/unknown"/>
</RDF:Description>
Also found a few other entries with "application/unknown" and "application/".
After dropping the bad entries it works. Only question is what messed up the file in first place? And why? I guess only Firefox touch it.
|
||
Comment 3•20 years ago
|
||
*** Bug 323322 has been marked as a duplicate of this bug. ***
|
||
Comment 4•20 years ago
|
||
Okay. You'll all been great but it appears that the problem is ours and not Firefox so can we remove this from your website? I'd really rather we didn't have folks accessing our private site services. Thanks for everything!
Coleen
|
|
||
Comment 5•19 years ago
|
||
Resolving invalid as per comment #4.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
I am now seeing this behavior in FF 2.0.0.2 on OS X. Live headers and my server confirm that FF is sending PDFs as a application/x-download MIME type
|
|
||
Comment 7•17 years ago
|
||
Heh. Comment 4 wasn't even about this bug, so it certainly doesn't make this invalid.
Resolution: INVALID → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•