Re: MIME type parameters

On 01/21/2014 02:51 PM, Jack Bates wrote:
> 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
>

Are you seeing this happening somewhere? AFAIK we don't parse the 
semicolon for plugin selection anyway, so this would not match.

> 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

If a plugin wants to handle all parameters it makes appending anything 
to the content mime type rather pointless. Indeed, java already 
registers application/x-java-vm.

> 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

This is already true in gecko as we require a full match

> 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
>
But java does register just application/x-java-applet -- this behavior 
makes version selection useless. Content requesting 
"application/x-java-applet;version=2.0" would get the 1.7 plugin. In 
fact, putting ;anything=anything in content would not affect whether or 
not you get java, we may as well just strip parameters.
> 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".)
My installed java plugin registers all supported versions:

application/x-java-applet    IcedTea    class,jar
application/x-java-applet;version=1.1    IcedTea    class,jar
...
application/x-java-applet;version=1.4.2    IcedTea    class,jar
application/x-java-applet;version=1.5    IcedTea    class,jar
application/x-java-applet;version=1.6    IcedTea    class,jar
application/x-java-applet;version=1.7    IcedTea    class,jar
application/x-java-applet;jpi-version=1.7.0_50    IcedTea class,jar
...

So the intent seems to be that if a site embeds 
"application/x-java-applet;version=1.8" it wouldn't match my 1.7 plugin, 
but all versions <=1.7 would. Making application/x-java-applet match 
everything would just disable all version selection. Additionally, they 
seem to specifically only register ";jpi-version=1.7.0_50" for one 
reason or another -- giving jpi-version=1.7.0_06 to the plugin seems 
incorrect.

Now, how many of the sites blindly requesting a specific jpi-version 
actually need that exact update revision? We could guess not many and 
just launch java anyway, but it doesn't seem like correct or logical 
behavior.

>>> 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?
> _______________________________________________
> dev-tech-plugins mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-plugins