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 Summary: Major issues with jsp:param in jsp:include and jsp:forward Product: Tomcat 4 Version: 4.1.3 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This is related to bug 9361, which I also filed, but I have now run across a number of more substantive, related issues. Tomcat 4.1.3 (and 4.1.2 and I'm not sure how far previously) take: <jsp:include ....> ... <jsp:param name="foo" value="<%=bar%>"/> ... and generate something like JspEngine.include( ... + "&foo=" + java.net.URLEncoder.encode( bar ) ... ); whereas Tomcat 3.x did something like JspEngine.include( ... + "&foo=" + bar ... ); [Yes, I know the class is not actually "JspEngine", but you get the idea.] This was apparently done to fix issues when bar.toString()'s result contained &, =, or other special characters. Unfortunately, this change has a number of critical issues: 1) As per 9361, if 'bar' is null, then this throws an exception, whereas most every servlet engine around (including Tomcat 3.2.x and 3.3.x) do not. 2) If 'bar' is not a String, then the JSP page will no longer compile, whereas non-String variables could be used in this context previously and in other JSP engines. 3) java.net.URLEncoder.encode() does not properly handle non-ASCII or at least non-Latin characters. One has to do something like get the string bytes as per UTF8 then URLEncode the string formed from these bytes (interpretting each byte as a char) -- or more efficiently do this all in a single pass. Thus the original intent of using URLEncoder.encode() is not fully accomplished by the change anyway. As it stands now, Tomcat 4.1.x seriously cripples jsp:param as it is commonly used. If this is as per the JSP 1.2 spec, please point this out (though I'd have trouble believing this). I strongly suggest a single String JspEngine.encode( Object obj ) method that will return "" for a null object and otherwise to obj.toString(), UTF8 encode and URL encode this result. As it is now, I suspect we were better off overall with the Tomcat 3.x jsp:param code generation, i.e. a heck of a lot of big, real apps run just fine on it without running afoul of URL encoding issues. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
