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

2002-02-12 Thread bugzilla

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|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-02-12 23:40 ---
Tomcat has no way to reliable way to tell what is or what isn't an absolute URL,
except checking if it begins with http or https (which I think is how is
implemented now). If you find a nice way to improve this and support your use
case, please submit a patch.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




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

2002-02-05 Thread bugzilla

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|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-02-05 12:59 ---
Send redirect doesn't really do that (look at the javadocs).
Instead, set the header and the status code yourself, and it should work.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




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

2002-02-05 Thread bugzilla

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]