Re: MIME type parameters

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.

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