Re: MIME type parameters

On 13/01/14 07:40 AM, Benjamin Smedberg wrote:
> 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.

A) If each parameter in the content MIME type must be matched by a 
parameter in the plugin MIME type ("forward logic") then:

If a plugin wants to handle only a specific parameter
(e.g. application/x-java-applet;jpi-version=1.6.0_06) it *cannot*:
content application/x-java-applet matches
plugin application/x-java-applet;jpi-version=1.6.0_06

If a plugin wants to handle all parameters it *cannot*:
content application/x-java-applet;jpi-version=1.6.0_06 does not match
plugin application/x-java-applet

Whereas,

B) If each parameter in the plugin MIME type must be matched by a 
parameter in the content MIME type ("reverse logic") then:

If a plugin wants to handle only a specific parameter it *can*:
content application/x-java-applet does not match
plugin application/x-java-applet;jpi-version=1.6.0_06

If a plugin wants to handle all parameters it *can*:
content application/x-java-applet;jpi-version=1.6.0_06 matches
plugin application/x-java-applet

Maybe there are other reasons why Chromium implements behavior B) but 
support for these two cases could be one reason. Another reason is that 
content in the wild that works given behavior B) does not work given 
behavior A)

(Firefox complains to the user "A plugin is needed to display this 
content." In Chrome it "just works".)

>> 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.

I understand. Does adopting a behavior that is already widely deployed 
(by Chrome) reduce that danger/risk?