DO NOT REPLY [Bug 10671] New: - Major issues with jsp:param in jsp:include and jsp:forward

[bu...@apache.org]

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: tomcat-dev@jakarta.apache.org
        ReportedBy: jessh@ptc.com


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>