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 occurs: JAR https://my.server.domain.com/HelloWorld.jar not found Notes: * 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): firefox 14.0.1-1.fc17 Java version is 1.7.0_05-icedtea How reproducible: 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 Actual results: over https one gets JAR https://my.server.domain.com/HelloWorld.jar not found Expected results: applet runs like over http Additional info: 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 why.
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: http://koji.fedoraproject.org/koji/packageinfo?packageID=37 http://koji.fedoraproject.org/koji/packageinfo?packageID=4569 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: http://sourceforge.net/projects/weblogin . 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: http://www.muc.de/~af/sw/weblogin-1.2.1-0.src.rpm * 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: https://your.hostname.xy:491/unix_session/login.php 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 ?) Notes: * 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 https://bugzilla.redhat.com/show_bug.cgi?id=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.