Closed Bug 364400 Opened 18 years ago Closed 7 years ago

URI deduced for Java applets is badly wrong

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jwkbugzilla, Unassigned)

References

()

Details

The page on http://www.java.com/en/download/help/testvm.xml has an applet:

  <applet code="testvm.class" codebase="http://www.java.com/applet">

The URI reported for this applet to content policies is http://www.java.com/testvm.class - nsObjectLoadingContent::LoadObject() uses nsContentUtils::NewURIWithDocumentCharset() to resolve the URI against the codebase. The actual location of the applet is http://www.java.com/applet/testvm.class, so Java seems to use a different scheme to resolve the URI. Putting a slash at the end of the codebase makes Gecko and Java agree on the URI of course.

This can be easily tested with the Adblock Plus extension - install it, go to the page and click the "Adblock" tab on the object. Note the wrong address being displayed.

Btw, bug 79596 looks similar but it seems to be a different problem.
Blocks: abp
I investigated this issue further and found out that there are far more issues with the way applet URIs are deduced. Also, this issue not only affects content policies, security checks work on the same wrong URI. Here some examples (real request URL verified with a sniffer):

-------------------------------------------------------------

    <applet type="application/x-java-applet" code="Test.class" codebase="http://example.com/"></applet>

Real requests:
http://example.com/Test.class
http://example.com/Test/class.class

Reported URI:
http://example.com/Test.class

-------------------------------------------------------------

    <applet type="application/x-java-applet" code="Test" codebase="http://example.com/test"></applet>

Real requests:
http://example.com/test/Test.class

Reported URI:
http://example.com/Test

-------------------------------------------------------------

    <applet code="Test.Foo.Bar" codebase="http://example.com/" archive="test.jar"></applet>

Real requests:
http://example.com/test.jar
http://example.com/Test/Foo/Bar.class

Reported URI:
http://example.com/Test.Foo.Bar

-------------------------------------------------------------

    <object type="application/x-java-applet" code="Test.Foo.Bar" codebase="http://example.com/" archive="test.jar"></object>

Real requests:
http://example.com/test.jar
http://example.com/Test/Foo/Bar.class

Reported URI:
http://example.com/

-------------------------------------------------------------

The issues I see so far:

* Codebase should always be treated as a directory, regardless of whether it has a trailing slash
* The translation from class names to file names isn't as trivial as Gecko thinks it is. Java changes dots into slashes in order to find the class path and adds ".class" then. If the class name already contains ".class", Java will try the class name both with and without an additional ".class".
* Gecko ignores the archive attribute entirely - yet the archive will be requested in addition to trying to get the class directly.
* Gecko only recognizes applets defined with the <applet> tag, same rules apply to applets defined via <object> tag however.
Summary: Wrong applet URI reported to content policies (codebase resolution) → URI deduced for Java applets is badly wrong
Testing a little further I found that Java interprets the data attribute for the <object> tag but not for the <applet> tag. If the data attribute is present the URI is what Gecko expects - meaning for example that codebase isn't being treated as a directory, and there is no autocompletion for the file extension (actually, that attribute seems to be handled by Gecko so this isn't really surprising). No issues here. However, the archive attribute is more fun than what I showed above. And there is an object attribute that is treated the same as the code attribute only that it is a file name already and not a class name.

-------------------------------------------------------------

    <applet code="Test.Foo.Bar" codebase="http://example.com/" archive="http://example2.com/test.jar,test2.jar"></applet>

Real requests:
http://example2.com/test.jar
http://example.com/test2.jar
http://example.com/Test/Foo/Bar.class

Reported URI:
http://example.com/Test.Foo.Bar

-------------------------------------------------------------

<applet object="test.image" codebase="http://example.com/test" archive="test.jar"></applet>

Real requests:
http://example.com/test/test.jar
http://example.com/test/test.image

Reported URI:
http://example.com/test

-------------------------------------------------------------
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.