Re: MIME type parameters

On 1/11/2014 6:08 PM, Jack Bates wrote:
>
> I understand that the current and intended Firefox behavior is
> 1) to match MIME type parameters literally
> (e.g. application/basic-example-plugin !=
> application/basic-example-plugin;foo=bar)
> and 2) when content uses
> application/x-java-applet;jpi-version=1.6.0_06
> and the Java plugin registers
> application/x-java-applet
> (and application/x-java-applet;jpi-version=1.6.0_50)
> do not find the plugin
> (the Oracle documentation is irrelevant to this case).
>
> I don't know the rationale in favor of this behavior
> (is it the correct or the best behavior?)
>
> e.g. The behavior in Chromium is to match MIME types when each 
> parameter in the type registered by the plugin is matched by a 
> parameter in the type from the content.
>
> https://code.google.com/p/chromium/codesearch#chromium/src/net/base/mime_util.cc&l=545 
>
This seems like reverse logic:

If the plugin says "I support application/x-java-applet;version=1.1" 
then it at least makes sense to assume that it also supports 
application/x-java-applet.

But when content requests application/x-java-applet;jpi-version=1.6.0_06 
and the plugin claims support for 
application/x-java-applet;jpi-version=1.6.0_50 it doesn't make sense for 
those to match. They *shouldn't* match.

>
> I propose changing the Firefox behavior so that it does work, too.
> (But I don't know the rationale in favor of retaining the current 
> intended behavior.)

Actually our rationale for this is pretty straightforward: the NPAPI is 
both a legacy technology and very under-documented. From our perspective 
making any changes to this is potentially dangerous and not worth the risk.

--BDS