Re: MIME type parameters

On 29/01/14 02:47 PM, John Schoenick wrote:
> On 01/29/2014 02:12 PM, Jack Bates wrote:
>> 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).
>
> But, does oracle java currently "want" to handle all versions? They
> register a list of versions up to and including 1.7, passing a site that
> requests version=1.8 to the plugin seems incorrect. However, if java is
> already checking this parameter itself, it may make sense for the
> browser to ignore it.

The documented behavior [1] of the Java plugin (by Sun/Oracle) given a 
specific JRE version (for example, a particular update release like 
"1.5.0_11") is to fall back on the latest available JRE on the machine. 
(The documentation mentions that all version selection mechanisms use 
the same underlying code path):

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

This is what happens in Chrome, but it's not currently supported by 
Firefox (except by hardcoding a generated list of every update release).

Content like the following is already handled by the Java plugin, 
regardless of the java_version value (in Firefox as in other browsers) 
so I think it does make sense for the plugin to handle all values of the 
;jpi-version MIME type parameter (as it does in other browsers but 
currently not in Firefox):

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

>> To reduce the danger/risk of this change, I propose adopting the same
>> behavior that is already widely deployed by Chrome.
>
> Our behavior predates chrome and many legacy apps were likely designed
> against it. A sample size of one broken site is not really enough to
> judge which method is least destructive -- especially since a large
> portion of applets are likely legacy tools on corporate intranets.

This change only affects cases where Firefox currently complains to the 
user that "A plugin is needed to display this content" despite a plugin 
being installed, in which cases the current behavior already seems 
pretty destructive.

(This morning I tested Internet Explorer and the Sun/Oracle Java plugin 
and in that case also, content like the following is handled by the 
plugin, regardless of the ;jpi-version MIME type parameter value:

http://nottheoilrig.com/java/201401300/

On the same machine, Firefox complains to the user "A plugin is needed 
to display this content" despite the same Java plugin being installed.)