Closed Bug 270228 Opened 20 years ago Closed 20 years ago

Plugin will never be invoked if URL lacks proper extension (Content-Type is ignored)

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: kevinb9n, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This may be the same problem as bug 140975 -- please forgive if so.  Even if
this is the same bug, I believe this is a more general statement of it.

Basically, firefox seems to completely ignore the Content-Type header and key
only off the extension when determining what plugin to use.

Would REALLY like to know a workaround if one exists!

Reproducible: Always
Steps to Reproduce:
1. Make sure you have the Acrobat Reader (or other PDF-viewer) plugin installed.
2. Go to about:plugins and verify that this plugin appears on the line for type
"application/pdf"
3. Go to http://s91988715.onlinehome.us/cgi-bin/getpdf

Actual Results:  
Was prompted to launch Preview (mac) or xpdf (linux).  These are the correct
helper apps, but the plugin was circumvented.  I have no option to manually
choose the plugin.

Expected Results:  
Displayed the content using the Acrobat plugin.

I've seen this in Firefox 1.0 on both linux and macosx.

Note that this link I provided is sending the following headers:

Content-Disposition: attachment; filename=TOC.pdf
Content-Length: 22109
Content-Type: application/pdf
"Content-Disposition: attachment; filename=TOC.pdf"

This means that Mozilla MUST show a save/as dialog instead of interpreting it
internal or by a plugin.

-> invalid
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.