Re: MIME type parameters

On 28/01/14 02:07 PM, John Schoenick wrote:
> 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.

The IcedTea-Web authors want the plugin to handle
application/x-java-applet;jpi-version=1.6.0_06,
application/x-java-applet;jpi-version=1.6.0_07, etc. [1]
(as it already does when used with Chrome) but this behavior is not 
currently supported by Firefox except by hardcoding a generated list of 
every update release into the plugin, which the plugin authors feel is 
"terrible" and a workaround:

[1] 
http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/25666

The recommended version selection mechanism [2] is with <applet>, 
<object> or <embed> markup, e.g.

<embed java_version="1.6.0_06" type="application/x-java-applet"></embed>

[2] 
http://www.oracle.com/technetwork/java/javase/index-141751.html#MECHANISMS

In Firefox (as in other browsers) this content is already handled by the 
IcedTea-Web plugin, regardless of the java_version value.

The plugin is still free to apply the same logic with which it handles 
the java_version <embed> attribute to the ;jpi-version MIME type 
parameter, if it chooses.

I propose supporting plugins that want to handle all values of a MIME 
type parameter, and in particular the IcedTea-Web plugin handling all 
values of the ;jpi-version MIME type parameter (as the plugin authors 
want and already works in Chrome).

To reduce the danger/risk of this change, I propose adopting the same 
behavior that is already widely deployed by Chrome.