improper handling of %2F in query string on Windows

RESOLVED FIXED in mozilla1.1alpha


Core Graveyard
Java: OJI
17 years ago
7 years ago


(Reporter: Thad Humphries, Assigned: Joshua Xia)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [URL parsing], URL)



17 years ago
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  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 ( is a WinNT box running Mozilla 0.9.2+
nightly build for July 17, 2001.  The other address ( is a RedHat
Linux box (vr 6.2) running the same Mozilla build but for Linux.  Comments are
interspersed and prefixed with ### - - [23/Jul/2001:13:00:42 -0400] "GET /~thad/home.html HTTP/1.1" 304 - - - [23/Jul/2001:13:00:52 -0400] "GET /optix-web/LogonApplet.jsp
HTTP/1.1" 200 1531 - - [23/Jul/2001:13:00:59 -0400] "GET /optix-web/applets/logon.jar
HTTP/1.1" 200 5158
### the applet loads - - [23/Jul/2001:13:01:08 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x%2Fy HTTP/1.1" 200 1487 - - [23/Jul/2001:13:01:11 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x/applets/logon.jar HTTP/1.1" 200 1487 - - [23/Jul/2001:13:01:11 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x/applets/null HTTP/1.1" 200 1487 - - [23/Jul/2001:13:01:11 -0400] "GET
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 - - [23/Jul/2001:13:01:45 -0400] "GET /optix-web/LogonApplet.jsp
HTTP/1.1" 200 1531 - - [23/Jul/2001:13:01:48 -0400] "GET /optix-web/applets/logon.jar
HTTP/1.1" 200 5158
### the applet loads - - [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

Comment 1

17 years ago
Assignee: asa → harishd
Component: Browser-General → Parser
Ever confirmed: true
QA Contact: doronr → bsharma

Comment 2

16 years ago
I am almost sure that this is not a parser issue. Will look into it anyway :-/
Target Milestone: --- → mozilla0.9.5


16 years ago
Priority: -- → P3


16 years ago
Assignee: harishd → darin

Comment 3

16 years ago
This could be URL parsing error. Giving bug to darin.
sigh. Another one of these.
Component: Parser → Networking
QA Contact: bsharma → benc

Comment 5

16 years ago
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

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?

Comment 6

16 years ago
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 ( is the WinNT box; the other address
( is Linux.  Here is the access_log (from Apache 1.3): - - [26/Sep/2001:12:02:25 -0400] "GET /~thad/home.html HTTP/1.1" 200 10030 - - [26/Sep/2001:12:03:01 -0400] "GET /optix-web/LogonApplet.jsp
HTTP/1.1" 200 2107 - - [26/Sep/2001:12:03:18 -0400] "GET /optix-web/applets/logon.jar
HTTP/1.1" 200 7273 - - [26/Sep/2001:12:03:58 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x%2Fy HTTP/1.1" 200 2063 - - [26/Sep/2001:12:04:00 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x/applets/logon.jar HTTP/1.1" 200 2063 - - [26/Sep/2001:12:04:00 -0400] "GET
/optix-web/LogonApplet.jsp?foo=x/applets/null HTTP/1.1" 200 2063 - - [26/Sep/2001:12:04:00 -0400] "GET
HTTP/1.1" 200 2063 - - [26/Sep/2001:12:04:16 -0400] "GET /~thad/home.html HTTP/1.1" 304 - - - [26/Sep/2001:12:04:40 -0400] "GET /optix-web/LogonApplet.jsp
HTTP/1.1" 200 2107 - - [26/Sep/2001:12:04:41 -0400] "GET /optix-web/applets/logon.jar
HTTP/1.1" 200 7273 - - [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 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.

Comment 7

16 years ago
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.

Comment 8

16 years ago
andreas: you interested in taking this bug?

Comment 9

16 years ago
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 ... 

Comment 10

16 years ago
ok.. no problem.. any help you could give would of course be appreciated :)

Comment 11

16 years ago
Okay, I did some tests with linux and some debugging: works fine, the
applet gets initialized. 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.

Comment 12

16 years ago
-> 0.9.6 (reducing severity to major)
Severity: blocker → major
Target Milestone: mozilla0.9.5 → mozilla0.9.6


16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7


16 years ago
Whiteboard: [url-parsing]


16 years ago
Whiteboard: [url-parsing] → [URL parsing]

Comment 13

16 years ago
the testcase seems to have disappeared... reporter: can you check on the testcase?

Comment 14

16 years ago
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!

Comment 15

16 years ago
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

Comment 16

16 years ago
thx for the info.

Comment 17

16 years ago
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

-> plugins (punt if not appropriate)
Assignee: darin → av
Component: Networking → Plug-ins
QA Contact: benc → shrir

Comment 18

16 years ago
-->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 
Assignee: av → joe.chou
Component: Plug-ins → OJI
QA Contact: shrir → pmac

Comment 19

16 years ago
No resources right now, move milestone to mozilla1.1.
Target Milestone: mozilla0.9.7 → mozilla1.1

Comment 20

16 years ago
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

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?

Comment 21

16 years ago
*** Bug 132049 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
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
- 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.


15 years ago
QA Contact: pmac → petersen

Comment 23

15 years ago
reassign to me
Assignee: joe.chou → joshua.xia

Comment 24

15 years ago
->FIXED per comment 22
Last Resolved: 15 years ago
Resolution: --- → FIXED


7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.