DO NOT REPLY [Bug 6208] New: - Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6208>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6208

Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface

           Summary: Bug in Tomcat's implementation of the sendRedirect
                    method of the HttpServletResponse interface
           Product: Tomcat 4
           Version: 4.0.1 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: brentboyer@hotmail.com


BACKGROUND:
I need to sign some Javascript files (because they will do some priveleged
actions) that are part of an html page that will be dished back to a modern
Mozilla client (e.g. Mozilla 0.9.7).

Mozilla has changed their code signing procedure, so that you must now place
your entire html page in a jar file, and then sign that entire jar file. 
Details may be found in:
    http://www.mozilla.org/projects/security/components/signed-scripts.html#signing

A key thing with modern Mozilla is that you must now use a special jar url
format to access the signed data; see the "Accessing a Signed Page" subsection
of the above link.

In my case, the jar url is something like:
    jar:http://somehost/controllerMoz.jar!/controllerMoz.html

(To be thorough, I have hand pasted the above url into Mozilla and verified that
Mozilla can fetch it and handle it correctly, so there is no problem with it.)

THE BUG IN TOMCAT:
Given the above, I have a servlet (an HttpServlet, to be precise) which will (if
the client has provided correct login information) send a redirect to the client
telling it to load the above url.  The java code for this is:
    res.sendRedirect("jar:http://somehost/controllerMoz.jar!/controllerMoz.html");

(where res is the HttpServletResponse that is passed in to the doPost method of
every HttpServlet).

Unfortunately, when the client attempts to login, all he gets is a 302 error
code page.

In trying to diagnose the problem, I set the webapps debug level to 9 and
activated a RequestDumperValve in the server.xml file.

This found the problem: it turns out that Tomcat is actually NOT sending back
the requested url to the client.  Instead, it sends back (the following is
copied from the log file):
    RequestDumperValve[/cobrowser]:             header=Location=jar:
In other words, Tomcat is for some reason chopping off the remainder of the full
redirect jar url.

What Tomcat SHOULD have done is sent back
   RequestDumperValve[/cobrowser]:             header=Location=jar:http://
somehost/controllerMoz.jar!/controllerMoz.html

I am (probably falsely) assuming that the sendRedirect method is chopping it
off; sendRedirect is probably working, but something later in Tomcat is
mutilating it.  As near as I can tell, this is a bug.

Please get back to me ASAP on this!!!

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>