improper handling of %2F in query string on Windows

RESOLVED FIXED in mozilla1.1alpha

Status

Core Graveyard
Java: OJI
P3
major
RESOLVED FIXED
17 years ago
7 years ago

People

(Reporter: Thad Humphries, Assigned: Joshua Xia)

Tracking

Trunk
mozilla1.1alpha
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [URL parsing], URL)

(Reporter)

Description

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
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

Comment 1

17 years ago
->parser
Assignee: asa → harishd
Status: UNCONFIRMED → NEW
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

Updated

16 years ago
Priority: -- → P3

Updated

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
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?
(Reporter)

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 (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.

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:

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.

Comment 12

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

Updated

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

Updated

16 years ago
Whiteboard: [url-parsing]

Updated

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?
thanks!

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!
(Reporter)

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
Windows.

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
layer.

-> plugins (punt if not appropriate)
Assignee: darin → av
Status: ASSIGNED → NEW
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 
'application/x-java-applet;version=1.3'
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
(Reporter)

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
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?

Comment 21

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

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
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.

Updated

15 years ago
QA Contact: pmac → petersen
(Assignee)

Comment 23

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

Comment 24

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

Updated

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.