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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
