User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 StumbleUpon/1.909 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 StumbleUpon/1.909 Some pdf:s I load in Firefox downloads to the downloads folder and some are displayed inline Example of pdf that is displayed within Firefox http://www.dsv.su.se/utbildning/su/ansokanOK.pdf Example of pdf that is downloaded http://www.svd.se/statiskt/ledare/pdf/get_file.asp?Filename=SVD-20040519-A04%20LED%204.pdf&week=21 I use the PDF Browser Plugin 2.0 I believe (but I am not sure) the problem is that URL:s which don't end with a pdf-extension are downloaded even though the mime type in the http-headers are application/pdf Reproducible: Always Steps to Reproduce: 1. Load any of the links above 2. 3. Actual Results: One of the PDF:s is downloaded and one is displayed within PDF Expected Results: Act consistently (and give me a good interface for setting plug-in preferences)
--> File Handling
Assignee: firefox → bugs
Component: General → File Handling
This is also wrong in Mozilla and Camino. Note also that the file that is downloaded doesn't have a .pdf extension, so it's not double-clickable. Behaves correctly in Safari (i.e. displays the PDF with the plug-in).
I can see it with Firefox windows 2003 trunk 20040522 Not sure if it's a bug because it happens with IE6 too ;-)
OS: MacOS X → All
Hardware: Macintosh → All
[timeless@viper timeless]$ HEAD http://www.dsv.su.se/utbildning/su/ansokanOK.pdf200 OK Connection: close Date: Tue, 25 May 2004 22:02:09 GMT Accept-Ranges: bytes ETag: "e40f3-150e1-407fc406" Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_python/2.7.8 Python/2.1.3 PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6g Content-Length: 86241 Content-Type: application/pdf Last-Modified: Fri, 16 Apr 2004 11:31:18 GMT Client-Date: Tue, 25 May 2004 22:02:42 GMT Client-Response-Num: 1 [timeless@viper timeless]$ HEAD 'http://www.svd.se/statiskt/ledare/pdf/get_file.asp?Filename=SVD-20040519-A04%20LED%204.pdf&week=21' 200 OK Cache-Control: private Connection: close Date: Tue, 25 May 2004 22:02:21 GMT Server: Microsoft-IIS/5.0 Content-Length: 93385 Content-Type: application/pdf; Charset=UTF-8 Client-Date: Tue, 25 May 2004 22:02:55 GMT Client-Response-Num: 1 Content-Disposition: attachment; filename=SVD-20040519-A04 LED 4.pdf The second url is spitting out an invalid content-disposition. tell them they're broken and should quote filenames that contain spaces. I believe the problem is that we're checking the content type strictly. So application/pdf; Charset=UTF-8 is not matched against the plugin.
Assignee: bugs → nobody
Component: File Handling → Plug-ins
Product: Firefox → Browser
QA Contact: aebrahim → core.plugins
Summary: Randomly (?) some PDF:s displays within Firefox (via plugin) and some are downloaded → Plugins don't match things which have Charset tags randomly attached
Version: unspecified → Trunk
would someone please explain what it means to have an application/pdf with a charset specified? If no one can, then this like the other error is tech evang fodder.
I believe it is meaningless. The question is then: should meaningless content type parameters be ignored? I have not found RFC text that speaks specifically to that. In the absence of such text, I don't know that there's a compelling reason to change Mozilla's current behavior.
Hm... A possible reason to ignore meaningless media type parameters: parameters could be added in a revision to an already-defined type.
Okay, HTTP/1.1 (3.7) says: Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, implementations SHOULD only use media type parameters when they are required by that type/subtype definition. Note: "SHOULD", not "MUST". What the server is sending here is certainly a bit goofy. But I really think Mozilla should be handing the datastream off to the plug-in regardless of the media type parameters.
Status: UNCONFIRMED → NEW
Ever confirmed: true
cc: darin, who probably can tell us who is right :)
I tried creating a testcase, but can't figure how to get apache to send that content-type.
I'm pretty sure we've fixed this in the meantime.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.