tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10671] - Major issues with jsp:param in jsp:include and jsp:forward
Date Wed, 01 Oct 2003 12:02:18 GMT
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

kahroo@hot.ee changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From kahroo@hot.ee  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message