8.18 KB, application/x-rar-compressed
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:220.127.116.11) Gecko/2010020220 Firefox/3.0.18 GTB6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:18.104.22.168) Gecko/2010020220 Firefox/3.0.18 GTB6 (.NET CLR 3.5.30729) Since installation of the last firefox-update the content-type of an uploaded pdf-file in our asp.net-application ist sent as "text/x-plain-to-save" instead of "application/pdf". The problem should not be specific to asp.net since the upload-control is rendered as normal input-element. Reproducible: Always Actual Results: content-type is "text/x-plain-to-save" Expected Results: content-type should be "application/pdf"
Created attachment 471968 [details] rar-file containing a test case (website - one procedure 8KB) This mini website in PHP allows to upload PDF files in a directory. On receive the file-name, file-type (as reported by the uploading client) and the file-size is shown. (maximum size is restricted to 2 MB). When uploading from Windows the reported mime-type is 'application/pdf', when used from Mac OS the type is reported as 'application/save-as'. This happens with firefox only, but not with safari.
please note: Since several days all user working with Mac OS report they cannot upload PDF-files with firefox anymore, while uploads with safari work well. It seems this is caused by firefox reporting an other mime-type (application/save-as) instead 'application/pdf'. The problem is reproducible and constantly wrong. This behavior hinders a proper check, if the required file type has been uploaded or not. We had the choice to remove any file-type checking in the used procedures or to remove support for firefox - we decided - for now - to change security and to remove the file-type checking.
According to dupe bug 508647, this bug is platform: All All
Reporter, are you still seeing this issue with Firefox 4.0.1 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2011-05-30]
Version: unspecified → 3.0 Branch
The problem seems to be gone with FF4 and MAC thanks for removing the problem we still have some users with Win 7/x64 and FF 3.6.3 (x64 Namoroka build) where the problem seems to be similar, would thrust upon the idea that the problem is in the x64 code. While there is no FF4/x64 available we while wait there for FF5 hoping there will be then a "officially" supported x64 version.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
The bug is back, version 33.0.2
You need to log in before you can comment on or make changes to this bug.