When accessing a Java Server Page that loads an applet via the <jsp:plugin> tag, if the query string has a properly escaped forward slash in it (/, %2F), Mozilla for Windows mistakes this slash for part of the page's URL and not part of the query string. As a consequence, incorrect applet class is requested by the server and the applet cannot load. This bug has taken us a while to isolate but we've seen in on Mozilla for Windows (tested Win98, WinNT, and Win2000) at least since 0.7. This problem does **not** occur in Linux. To reproduce: In the location field of a Windows Mozilla, type in the URL for a JSP containing an applet (the URL given above is one such page). The applet loads. Now add to the URL a query string containing a %2F, for example http://demo1.optix.com/optix-web/LogonApplet.jsp?foo=x%2Fy. The applet will not initialize. Perform the same actions from a Linux Mozilla, and the applet will load both time. Below is the access_log file from my development server when I try the same steps. The first address (10.0.0.39) is a WinNT box running Mozilla 0.9.2+ nightly build for July 17, 2001. The other address (10.0.0.15) is a RedHat Linux box (vr 6.2) running the same Mozilla build but for Linux. Comments are interspersed and prefixed with ### 10.0.0.39 - - [23/Jul/2001:13:00:42 -0400] "GET /~thad/home.html HTTP/1.1" 304 - 10.0.0.39 - - [23/Jul/2001:13:00:52 -0400] "GET /optix-web/LogonApplet.jsp HTTP/1.1" 200 1531 10.0.0.39 - - [23/Jul/2001:13:00:59 -0400] "GET /optix-web/applets/logon.jar HTTP/1.1" 200 5158 ### the applet loads 10.0.0.39 - - [23/Jul/2001:13:01:08 -0400] "GET /optix-web/LogonApplet.jsp?foo=x%2Fy HTTP/1.1" 200 1487 10.0.0.39 - - [23/Jul/2001:13:01:11 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/logon.jar HTTP/1.1" 200 1487 10.0.0.39 - - [23/Jul/2001:13:01:11 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/null HTTP/1.1" 200 1487 10.0.0.39 - - [23/Jul/2001:13:01:11 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/com/optix/applet/logon/Logon.class HTTP/1.1" 200 1487 ### the applet fails to load; note what happened to the URL! ### the jar file comes from cache but the URL is wrong so ### the class can't load 10.0.0.15 - - [23/Jul/2001:13:01:45 -0400] "GET /optix-web/LogonApplet.jsp HTTP/1.1" 200 1531 10.0.0.15 - - [23/Jul/2001:13:01:48 -0400] "GET /optix-web/applets/logon.jar HTTP/1.1" 200 5158 ### the applet loads 10.0.0.15 - - [23/Jul/2001:13:01:52 -0400] "GET /optix-web/LogonApplet.jsp?foo=x%252y HTTP/1.1" 200 1487 ### the applet loads; the jar file comes from cache and ### the cache loads correctly
I am almost sure that this is not a parser issue. Will look into it anyway :-/
This could be URL parsing error. Giving bug to darin.
sigh. Another one of these.
There is no platform specific difference in core url parsing with %2F. The only windows specific stuff there is the \ -> / handling that will hopefully go away soon. This looks really strange to me .... Another question: Why do you escape / inside a query at all? It is valid there! Another thing: In 0.9.2 -> 0.9.3 query handling was changed and changed back in 0.9.4 on *all* platforms. Can you verify with >= 0.9.4 and attach new server logs for windows and linux clients?
Okay, I reran the same test with 0.9.4 on Windows NT and on Red Hat Linux 6.2. Same results. The first address (10.0.0.39) is the WinNT box; the other address (10.0.0.15) is Linux. Here is the access_log (from Apache 1.3): 10.0.0.39 - - [26/Sep/2001:12:02:25 -0400] "GET /~thad/home.html HTTP/1.1" 200 10030 10.0.0.39 - - [26/Sep/2001:12:03:01 -0400] "GET /optix-web/LogonApplet.jsp HTTP/1.1" 200 2107 10.0.0.39 - - [26/Sep/2001:12:03:18 -0400] "GET /optix-web/applets/logon.jar HTTP/1.1" 200 7273 10.0.0.39 - - [26/Sep/2001:12:03:58 -0400] "GET /optix-web/LogonApplet.jsp?foo=x%2Fy HTTP/1.1" 200 2063 10.0.0.39 - - [26/Sep/2001:12:04:00 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/logon.jar HTTP/1.1" 200 2063 10.0.0.39 - - [26/Sep/2001:12:04:00 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/null HTTP/1.1" 200 2063 10.0.0.39 - - [26/Sep/2001:12:04:00 -0400] "GET /optix-web/LogonApplet.jsp?foo=x/applets/com/optix/applet/logon/Logon.class HTTP/1.1" 200 2063 10.0.0.15 - - [26/Sep/2001:12:04:16 -0400] "GET /~thad/home.html HTTP/1.1" 304 - 10.0.0.15 - - [26/Sep/2001:12:04:40 -0400] "GET /optix-web/LogonApplet.jsp HTTP/1.1" 200 2107 10.0.0.15 - - [26/Sep/2001:12:04:41 -0400] "GET /optix-web/applets/logon.jar HTTP/1.1" 200 7273 10.0.0.15 - - [26/Sep/2001:12:04:56 -0400] "GET /optix-web/LogonApplet.jsp?foo=x%2Fy HTTP/1.1" 200 2063 I've tried this from a Windows 2000 box and Mozilla 0.9.4 and Netscape 6.1 with the same results. The query string uses %2F for / because it the URL is developed in a JSP or applet and is passed through java.net.URLEncoder.encode() so that it will be in the correct format. But never mind: ?foo=x/y gets the same results. To my mind, something is obviously wrong with Mozilla Windows. IE 5.5 and Netscape 4.7x for Windows handle this URL correctly.
Okay, thanks for testing it out with 0.9.4 and ruling some options out. On windows this looks like an attempt to resolve something as an relative urls which goes clearly wrong. As if something in windows-specific code uses something homegrown like Resolve which does not honor the query part. Maybe it is the jar stuff which has it's own Resolve method, but I don't think this is located in necko.
andreas: you interested in taking this bug?
Hmm ... my windows build environment is currently broken, so I'm somewhat at a loss with windows specific bugs ... but I can take a look around if I find some windows specific code that causes this problem ...
ok.. no problem.. any help you could give would of course be appreciated :)
Okay, I did some tests with linux and some debugging: http://demo1.optix.com/optix-web/LogonApplet.jsp?foo=x%2Fy works fine, the applet gets initialized. http://demo1.optix.com/optix-web/LogonApplet.jsp?foo=x/y does not work, the applet does not start. It would be nice to verify if these configuration also creates the bogus requests seen on windows. Thad? If indeed ?foo=x/y creates the same bogus requests this points to an unescape call that is there in the windows code but not in the linux code. But what code? Could be oji, could be the java plugin, which is platform and browser specific. I verified that necko's nsStdURL::Resolve method seems not to be used in creating additional requests beyond the first request for the page.
-> 0.9.6 (reducing severity to major)
the testcase seems to have disappeared... reporter: can you check on the testcase? thanks!
with the landing of the patch for bug 103916, we really need to reverify this bug. reporter: can you please help verify this bug? is it still a problem with a recent nightly build? thx!
Yes, the bug is still there. I downloaded the nightly build Zip file, extracted it, copied the NPOJI600.dll and NPJava1*.dll's from Netscape 4.7 plugins, and tried it out. Same failure. (JRE 1.3.1) Works fine in Mozilla 0.9.6 Linux, Netscape 4.7 (Windows and Linux), and IE 5.5 Windows.
thx for the info.
i don't see any differences between the two platforms in any of the URL parsing code that could explain this. perhaps it is something at the plugin interface layer. -> plugins (punt if not appropriate)
-->OJI. I cannot see anything special the plugin code could do the URL. I noticed though that the mimetype which is passed to the instantiation code reads 'application/x-java-applet;version=1.3'
No resources right now, move milestone to mozilla1.1.
I am incredulous! No fix for **how** long? So what is Mozilla (Sun?) telling me? What are the telling my customers? From here it sounds like "Forget Mozilla--USE INTERNET EXPLORER!" I know that is what my customers are concluding already--like the 500 users who are now being converted to IE because they need an HTML 4.0 compliant browser for their applications. Netscape 4.7 won't cut it (what's and <iframe>?) and, without this fix, Mozilla won't run many applets. There is no %2F bug in Mozilla Linux. There is no %2F bug in Netscape 4.7 on Windows or Linux. What gives?
*** Bug 132049 has been marked as a duplicate of this bug. ***
I just installed 1.0RC1 and tested this using JDK 1.3.1_02. It is fixed! My applets now load correctly. HOWEVER! the second time in a session that I load the applet, Mozilla hangs when I try to close the window. After about 45-60 seconds, Mozilla quits altogether with a memory error. I guess I need to search Bugzilla for this one but, briefly, I have tried it with 2 different PCs: - A PIII/166MHz with 96MB RAM and WindowsNT... Not surprising--a old dog tired machine. - A Dell Insprion, PIII/650MHz with 196MB RAM and Windows 2000. This machine should have sufficient performance. The JVM is set for -Xms96m -Xmx128m but I would think the Dell could handle that.
reassign to me
->FIXED per comment 22