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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2002-02-06 04:22 ------- Remy writes: >Send redirect doesn't really do that (look at the javadocs). I disagree. To quote from the javadocs (taken from the latest Servlet 2.3 spec): public void sendRedirect(java.lang.String location) throws java.io.IOException Sends a temporary redirect response to the client using the specified redirect location URL. This method can accept relative URLs... [discussion of relative URL handling ommitted] The first sentence above ("Sends a temporary redirect response...") says that it ought to do what I originally stated in my bug report. The next sentence states that the redirect Url CAN be, but does not HAVE to be, relative. Therefore, I conclude that as far as the javadocs go, I should be able to call res.sendRedirect("jar:http://somehost/controllerMoz.jar!/controllerMoz.html";); as stated in my original bug report. Now, in my original code, before I had to worry about digital signatures, I used relative Urls, doing stuff like res.sendRedirect("/controllerMoz.html"); which always worked. I just did an additional test with an http: absolute Url, res.sendRedirect("http://somehost/controllerMoz.html";); and the above also works fine; here is what the log file reports back for the response's header value: header=Location=http://166.84.156.61/controllerMoz.html which is exactly what I would expect. So tell me why http: protocol abosolute Urls should work just fine, but jar: protocol Urls get mutilated to just header=Location=jar: (when the response's header should be header=Location=jar:http://somehost/controllerMoz.jar!/controllerMoz.html ) Clearly, tomcat is somehow treating jar: absolute Urls differently than http: absolute Urls. Therefore, I maintain that this behavior is a bug, and I am reopening it. >Instead, set the header and the status code yourself, and it should work. OK -- that should constitute a reasonable workaround of the bug. Thanks for the suggestion (it is better than an uglier workaround that I thought of). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
