Plugins don't match things which have Charset tags randomly attached

RESOLVED WORKSFORME

Status

()

Core
Plug-ins
RESOLVED WORKSFORME
14 years ago
5 years ago

People

(Reporter: db, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
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)

Comment 1

14 years ago
--> File Handling
Assignee: firefox → bugs
Component: General → File Handling

Comment 2

14 years ago
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).

Comment 3

14 years ago
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

Updated

14 years ago
QA Contact: aebrahim

Comment 4

14 years ago
[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

Comment 5

14 years ago
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.

Comment 6

14 years ago
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.

Comment 7

14 years ago
Hm... A possible reason to ignore meaningless media type parameters: 
parameters could be added in a revision to an already-defined type.

Comment 8

14 years ago
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

Comment 9

14 years ago
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.

Comment 11

5 years ago
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.