Came across another interesting bug today involving Firefox and mime types. Firefox uses a file called mimeTypes.rdf (stored in your profile folder) to keep track of a) what application should be opening the file you’re downloading and b) what kind of file it should tell a server it’s sending when you upload a file. And it works … for the most part. See, if you download a PDF file from a server that (incorrectly) states that the content-type of the file is ‘application/unknown’, choose to open it using Adobe Acrobat and then check the box that says ‘Do this automatically from now on’, Firefox will store that bit of knowledge away in mimeTypes.rdf. Now go and use a web application that you upload files to and which analyzes the content-type of the files you’re uploading and upload a PDF file. If you’re using LiveHTTPHeaders, you’ll notice that you’re not sending ‘application/pdf’ but instead ‘application/x-download’.
It looks like this bug was filed in bugzilla a couple times and even acknowledged in their documentation, but has yet to be fixed. You can ‘fix’ the problem by deleting your mimeTypes.rdf file and restarting Firefox.
My jaw dropped to the floor when I found out this very annoying bug is still there in 2011 (I mean your post is dated 2007). This is just ridiculous – In a webmail software, I try to upload a pdf file and it’s sent as text/html. The result: the recipient gets a lot of garbage text and no PDF. Checked out the file you mention, mimetypes.rdf, only to find PDF listed as an extension for text/html format.
And still it exists in version 10.
I just had to remove my mimetypes rdf file today because it sent a header for a PDF upload as – get this – “/www/home/vesta/stamper/………./”
Where the heck it got that one from is beyond me, but it that same supposed mime type was listed against loads of file extensions in the rdf file.
Thx a lot for the hint. We had also this problem and I think we had never found this problem with the rdf-files. Now we have a clean solution for the problem.
thx also to Fabio: We had exactly the same problem.
Hi,
I am also facing the same problem. We are converting the ODT files to PDF in server and storing them on the server file system. But when user tries to view the stored PDF file (that is when user clicks the link to view PDF), the browser (FireFox version 11.0) opens the file as text file. When we checked the page info we got the type as text/plain.
Could you please explain the solution that you implemented to fix your problem? that will be a grate help for us to fix the problem we are facing.
Other thing is that when the user is using the view service internal to network then we are not facing this issue. If user is out side the network we are having this issue.
Hope to see the response soon.
Thanks,
-Amogh
Bug still here in good old 2015!
Takes three clicks to get a jpg to download, where an M4A file needs but one.