DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27705>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27705 HttpServletResponse.encodeURL does not work correctly with https [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2004-03-19 05:35 ------- I have read the specs (Servlet API version 2.3 and 2.4) and I must disagree with you. All that the spec says is that a webapp lives at a PATH on a server. This does not mean that when the server part changes that it _necessarily_ is a different webapp. All three the cases I mentioned in the bug could end up in the same webapp. 1) https - very likely will end up in the same webapp and I think addresses that have the same structure except for a protocol change must be encoded, otherwise you have no way of passing the user's session to a secure site. 2) port - less likely to end up in the same webapp, but it depends on the config of the connector between the web server and Tomcat. 3) server name - unlikley but may still end up in the same webapp because the web server may have virtual hosts all pointing to the same webapp. Please explain, why Tomcat has chosen to interpret the spec in such a restrictive way instead of looking at the problem logically. >From what I have read in some of the newsgroups is that a lot of people had to do their own encodeURL because Tomcat's implementation is too restrictive. PS: I realize you may have a lot of experience with this, but is is annoying if these "quirks" are not documented anywhere and one then usually spends a lot of time debugging a "feature". --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
