Red Hat Bugzilla – Bug 846763
Java applets do not run when both the applet spec in html and the jar come over https
Last modified: 2013-07-31 19:31:33 EDT
Created attachment 603063 [details]
Java applet to show the problem
Description of problem:
When a https delivered page specifies, that a java applet should be run
and the program (jar container) is also coming over https, an exception
JAR https://my.server.domain.com/HelloWorld.jar not found
* this happens only on Fedora 17 with Firefox 14.0.1
* it did not happen on any earlier Fedora version or any Redhat Enterprise Linux or any earlier Firefox
* it does NOT happen when the JAR file comes over http (plaintext)
* it does neither happen, when there is notable network delay between firefox and the server
* The web server delivering the data does not matter
* Java version is 1.7.0_05-icedtea
* it breaks my weblogin (sourceforge.net/projects/weblogin)
Version-Release number of selected component (if applicable):
Java version is 1.7.0_05-icedtea
use the attached file and
Steps to Reproduce:
1. unpack the attached file into a directory
2. run make (with gcj run: make JC="gcj -C" JAR=fastjar )
3. check, that the built HelloWorld.jar works: java -jar HelloWorld.jar
4. Put HelloWorld.html and HelloWorld.jar into a directory on a webserver, that is close to your fc17 client
5. Point the firefox-14.0.1-1.fc17 to download the HelloWorld.html over http
5a. It is helpful to run firefox from the command line, so one can see the Java output
6. Verify the applet shows up
7. Have firefox download the same file over https
over https one gets
JAR https://my.server.domain.com/HelloWorld.jar not found
applet runs like over http
Feel free to modify the HelloWorld.html to download over http, so that
the HelloWorld.html comes over http and the HelloWorld.jar comes over
https. This won't work either, but the other way round it works.
If you have a software network delay line, put them between the firefox
client and the server. It is likely to work this way, but i don't know
Can you please test it with firefox binary version from mozilla.org?
Downloaded 14.0.1 (and openjdk 1.7.0-05) and searched tons of web pages how to enable java in it. Nothing seems appropriate. With each and every firefox version it must be done differently and it's even different for 32 and 64 bit *sigh*. What symlink do i have to set where to what ?
Okay, and can you test which version is broken? Does it work with Firefox 10,11,12,13 for instance? You can download them from koji - http://koji.fedoraproject.org/koji/
Sorry i just need a hint.
I'll gladly test whatever version, but i need to know how to enable java applets in firefox 14 (or whatever version). The binary to download from mozilla is a 32 bit program and my fedora instance is a 64 bit. All libraries and java is in place also as 32 bit. I'm pretty sure, that there is not much to do to make java applets work. I just don't find it anywhere.
Thanks for any hint.
NO, you don't need to set up anything. You can download the old Fedora Firefox versions directly from koji (http://koji.fedoraproject.org/koji/). You can find the packages here:
Anyway, have it ever worked with any old Firefox version or not?
Sorry, it takes a bit of time to test on the different systems during the leisure time ...
So what i found until now:
On Fedora 16 with firefox 12.1 it works and also with 14.0.1.
So i guess it has to do with the java version.
Who is downloading the jar file, the firefox or already the java machine ?
On the Fedora 16 host a java-1.6.0-openjdk is installed, on
the Fedora-17 it's 1.7.0 (what is said to be more secure ...).
I tried to put 1.7.0 in effect on
the Fedora-16 system. Deinstalling the 1.6.0 forcibly probably
breaks more things on this system and i still need this one,
so this is currently not an option for me.
This brought me to the idea, that it might actually be bound
to the SSL certificates. The servers, where it's working, have a
certificate from a CA. However, this CA is not an official one
and has a self signed root certificate (not signed by one of
those institutions, whose certificates are typically coming
with browsers or other SSL clients)
so neither the firefox nor java should initially trust them.
The server, where it's not working, has a self signed certificate,
so there's no chain of trust. However, this imo still does not
explain, why it might work with one server and not with another one.
I'll do more tests in this direction.
Hm. On a server, where it failed, i created new
(still self signed) certificates. The others were
expired. Now it works. Seems, with the new java version
a problem with the certificate is not ignored, when
pressing "i understand the risks ..." when loading
the jar file. I'll try and check on the other server
and expect the same thing (will be able to do this Monday)
and report. So this is probably not a bug. However,
some hint in some release notes would be helpful.
It seems definitely to be the expired SSL certificate, that is not
accepted anymore when downloading the jar file.
If you think, this change from the earlier behaviour is not a bug,
feel free to close this issue.
However, imo a clear error message would save tons of time.
I guess it's a java issue, right? If not please reassign it back. Thanks!
And there's another thing, that seems to have changed and
i don't know, if this is intended or just accidentially causing
personyears of additional efforts worldwide:
With the ARCHIVE of a APPLET specification it is no longer possible
to use a relative path but now the entire URL must be given, what
makes things less flexible and i'd like to avoid such code.
(In reply to comment #10)
> And there's another thing, that seems to have changed and
> i don't know, if this is intended or just accidentially causing
> personyears of additional efforts worldwide:
> With the ARCHIVE of a APPLET specification it is no longer possible
> to use a relative path but now the entire URL must be given, what
> makes things less flexible and i'd like to avoid such code.
This is definitely not intentional. Can you please post a test tag I can try? (no need for applet itself, I can stick in a dummy applet).
I just tried relative ARCHIVE path locally with the version in F17 and it works for me.
Unbelievable. Now it works again. I spent hours to find out,
why i got again the message JAR <full-correct-url-to-the-jar> not found
from the jre.
Pasting the URL into the browser downloaded the jar without problem.
It drove me crazy, really. For a long time it works rock-solid and
then from one second to the other it does not work anymore and
strongly refuses to without any visible reason. Sorry for the effort.
Ah okay. NP.. glad it works again! :)
The problem was also visible with the simple example attached with this report.
However, i'd really like to know, if the subject of (probably not only my)
interest is working elsewhere on F17. The weblogin is what it's about:
Unfortunately, to test a bit of things must be done. I explain it here,
though i don't have any hope that someone will try.
* Download http://sourceforge.net/projects/afbackup/files/afbackup-3.5.8.tar.gz
Build (not afbackup, but the contained) albiutils:
* Put the file into your favourite rpm/SOURCES directory (on F17 it's
/root/rpmbuild/SOURCES when installing SRPMs)
* use the contained albiutils.spec.rh to build the installable RPM:
rpmbuild -bb /path/to/albiutils.spec.rh
* Install the created RPM. It contains a few things i often wonder how any
admin can do without. anyway.
* Download the development status of weblogin:
* Install it
* build the package: rpmbuild -bb /root/rpmbuild/SPECS/weblogin.spec
* install the package
rpm -ivh /root/rpmbuild/RPMS/<arch>/weblogin-1.2.1-0.<arch>.rpm
Try to use it starting and connecting sessions via web:
If it really works: Does it really work ? Are you sure ?
(it's always such a mess to make it work on any new Linux Distro release.
But it's cool BTW, isn't it ?)
* If selinux is enabled, the service does not start. selinux must be
configured to allow connections to the port (must rtfm how to do this)
* If you cannot connect, probably a firewall is active. So allow the
port with iptables or disable the firewall
* Don't be surprised, that the geometry setting made on the session
management page is ignored. This is subject to bug 847442
* To see Java error messages, run the firefox from the commandline.
With firefox 10 or higher there is no Java console, so when starting
via desktop they can't be seen.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.