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=10671>. 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=10671 Major issues with jsp:param in jsp:include and jsp:forward [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2003-10-01 12:02 ------- I lately ran into ALMOUST the same URL encoding decoding problem. As it seems no action is going to be taken I'll describe my situation so it could help in the desition making. First I need to put ISO-8859-4 characters on the URL (I know it's bad design and the next time I'll use underlying coding ;). For example the URL to be encoded is: "folder.do?path=/Uusim/täpiline". Now I use struts for createing the actual URL and so the URL is encoded in UTF-8. When tomcat decodes the request URL on the next step useing platform defaul encodeing ISO-8859-4 I get different result. As you all can see the problem could even be none of Tomcat's business but while figuring about the solutions I came up with a little example that makes it Tomcat's problem: Lets assume that I encode the url with URLEncoder.encode(java.lang.String) manually. Then struts will not find any unaceptable characters and leaves the URL alone (At least I hope so). Now I shouldn't have no problems with Tomcat's decodeing method. But the same problem comes up again when my application is distributed and the url location happens to be on a different server with a different encodeing. Now when the different server happens to be out of my hands and so the encodeing remains different then I'll have to deal with the encoding problem on application level and that's a bit stupid. So my opinion is that the URL encodeing and decodeing should allways be done in UTF-8 encodeing like the "World Wide Web Consortium" recommends. And maybe introduce a configuration parameter for extreme cases when some other server handles this issue incorrectly. I'd be happy to get any response concering this issue. PS! I also checked and think that this problem is currently up with both the 4.1.27 and 5.0.12 server versions. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
