JSP Include and URL encoding
Hi, I'm having problems including a JSP page from another JSP page using parameters with special characters. I looked through the archives, but couldn't find anything about this issue. I can encode a string, and the result is correct URLEncoder.encode(blåbærgrød, ISO-8859-1) But if I make an include with the same value jsp:include page=bar.jsp flush=true jsp:param name=word value=blåbærgrød / /jsp:include The special characters are replaced with question marks '?' (%3F). So the query string seen from bar.jsp becomes word=bl%3Fb%3Frgr%3Fd In fact the generated java code for the main jsp file contains this string also. So the problem is already during parsing or servlet generation. The requests character encoding is null. The page directive's pageEncoding attribute is ISO-8859-1 (or not present - doesn't make a difference. The user properties user.country and user.language are 'US' and 'en' respectively. Might that be the cause? The problem is on Tomcat 4.1.29 on Linux. By the way: I still haven't figured out whether Tomcat 4.1.30 is supposed to be able to run on JDK 1.3.1. Any help appreciated, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Include and URL encoding
(1)Set page directive attributes right (Maybe, pageEncoding = your platform encoding and charset = UTF-8) (2)Use a Servlet/JSP container other than Tomcat. For example, Resin from caucho.com. quote Scott Ferguson wrote: Actually, the underlying problem is a difficult one. Unfortunately, URLs don't have an official character encoding. It looks like we're drifting toward UTF-8 as a default, but that's not specified in the HTTP specifications. Because the HTTP request does not specify the URL encoding, the web server needs to guess. It's somewhat of an ugly problem. Today's JSPs have page directive, its contentType and pageEncoding attributes. A server doesn't need to bring rabbit out of a hat. Simply put in other words, Tomcat behavior is just substandard negligence. I have noticed that servlet generated from JSP by Resin has correct setCharacterEncoding() call even when the original JSP doesn't have the call. Resin may be called 'superstandard.' :) That somewhat translates into the Servlet/JSP forward/include issue. Resin's approach is to realize that the Java string for the URL/QueryString is 16-bits, so there's no need to do any encoding until there's a sendRedirect or something similar. -- Scott /quote Dennis Thrysøe wrote: Hi, I'm having problems including a JSP page from another JSP page using parameters with special characters. I looked through the archives, but couldn't find anything about this issue. I can encode a string, and the result is correct URLEncoder.encode(blåbærgrød, ISO-8859-1) But if I make an include with the same value jsp:include page=bar.jsp flush=true jsp:param name=word value=blåbærgrød / /jsp:include The special characters are replaced with question marks '?' (%3F). So the query string seen from bar.jsp becomes word=bl%3Fb%3Frgr%3Fd In fact the generated java code for the main jsp file contains this string also. So the problem is already during parsing or servlet generation. The requests character encoding is null. The page directive's pageEncoding attribute is ISO-8859-1 (or not present - doesn't make a difference. The user properties user.country and user.language are 'US' and 'en' respectively. Might that be the cause? The problem is on Tomcat 4.1.29 on Linux. By the way: I still haven't figured out whether Tomcat 4.1.30 is supposed to be able to run on JDK 1.3.1. Any help appreciated, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hiroshi Iwatani *stop cruelty* Annual number of institutionally euthanized cats and dogs including kittens and puppies: US 5 million, JP 500 thousand. How about your country? *for our better karma* - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Include and URL encoding
Hiroshi Iwatani wrote: (1)Set page directive attributes right (Maybe, pageEncoding = your platform encoding and charset = UTF-8) They are correct. The generated servlet already contains the wrong value '%3F'. (2)Use a Servlet/JSP container other than Tomcat. For example, Resin from caucho.com. I guess that could be an option, but this Tomcat instance is running at our service provider, so they would have to think so too. The problem has now been fixed by setting the language and country properties to 'da' and 'DK' respectively. This was apparently necesarry for the JSP parser to read the file correctly. quote Scott Ferguson wrote: Actually, the underlying problem is a difficult one. Unfortunately, URLs don't have an official character encoding. It looks like we're drifting toward UTF-8 as a default, but that's not specified in the HTTP specifications. Because the HTTP request does not specify the URL encoding, the web server needs to guess. It's somewhat of an ugly problem. For JSP includes this doesn't seem to be the problem. It is because of characters being replaced with '?' when reading the JSP. Thanks anyway, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Include and URL encoding
Dennis Thrysøe wrote: Hi, I'm having problems including a JSP page from another JSP page using parameters with special characters. I looked through the archives, but couldn't find anything about this issue. Try this URL: http://issues.apache.org/bugzilla/show_bug.cgi?id=23929 . Connector attributes mentioned there available since 5.0.19, as I understand. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Include and URL encoding
Veniamin Fichin wrote: Dennis Thrysøe wrote: Hi, I'm having problems including a JSP page from another JSP page using parameters with special characters. I looked through the archives, but couldn't find anything about this issue. Try this URL: http://issues.apache.org/bugzilla/show_bug.cgi?id=23929 . Connector attributes mentioned there available since 5.0.19, as I understand. Thanks, that may be related. Perhaps it could override the VM's language properties. But we fixed it by changing those properties instead. Besides the problem was on 4.1.29. -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP Include and URL encoding
Dennis Thrysøe wrote: Hiroshi Iwatani wrote: (1)Set page directive attributes right (Maybe, pageEncoding = your platform encoding and charset = UTF-8) They are correct. The generated servlet already contains the wrong value '%3F'. (2)Use a Servlet/JSP container other than Tomcat. For example, Resin from caucho.com. Oh no! (1)+ (2) is a SET. Not separate issues. Tomcat JSP translator doesn't use these page directive entries. So I called it substandard negligence. Anyway, thanks for an enjoyable reply! BTW, bugzilla 23929 OP is wrong. I guess that could be an option, but this Tomcat instance is running at our service provider, so they would have to think so too. The problem has now been fixed by setting the language and country properties to 'da' and 'DK' respectively. This was apparently necesarry for the JSP parser to read the file correctly. quote Scott Ferguson wrote: Actually, the underlying problem is a difficult one. Unfortunately, URLs don't have an official character encoding. It looks like we're drifting toward UTF-8 as a default, but that's not specified in the HTTP specifications. Because the HTTP request does not specify the URL encoding, the web server needs to guess. It's somewhat of an ugly problem. For JSP includes this doesn't seem to be the problem. It is because of characters being replaced with '?' when reading the JSP. Thanks anyway, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hiroshi Iwatani *stop cruelty* Annual number of institutionally euthanized cats and dogs including kittens and puppies: US 5 million, JP 500 thousand. How about your country? *for our better karma* - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
