You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2007/02/25 11:08:53 UTC

DO NOT REPLY [Bug 41696] New: - ApplicationDispatcher can't handle alternative HttpRequest-Implementation on forward

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41696>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41696

           Summary: ApplicationDispatcher can't handle alternative
                    HttpRequest-Implementation on forward
           Product: Tomcat 5
           Version: 5.0.16
          Platform: All
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: schroeder.wolfgang@gmx.net


Bug or feature?
I was trying to write a servlet-filter which should check on all posted
request-parameters and replace potential cross-site-scripting attacks from the
sent content by harmless equivalents.

First I subclassed HttpServletRequestWrapper and overrode getParameter,
getParameterMap, getParameterValues and getParameterValues but the
applicationdispatcher still used the parametermap from the wrapped request when
forwarding the request. This is not nice since the parameters of the forwarded
url are not added to the filters parametermap. It happens because
appclicationdispatcher internally unwraps all nested requests until an internal
type is reached. Everything works as expected as long as I dont forward the
request! 

Next I tried to implement interface HttpServletRequest on my own (simple
delegatepattern) because ApplicationDispatcher explicitly does NOT unwrap
NON-HttpServletRequestWrapper (ApplicationDispatcher.java line 871). But in this
case a ClassCastException is thrown at line 814 when unwrapping the request. At
this point Non-HttpServletRequestWrapper are not(!) ignored.

So in the end imho it comes down to these questions:
1. HttpServletRequestWrapper delegates calls on every method to it's wrapped
request. So in effect when merging requestparameters of the request with the
parameters of a forward-url, calls on getParameterMap etc are delegated to the
original request anyway as long as these methods are not overridden. I haven't
found a part in the spec where it is explicitly forbidden to alter
request-parameters when using a wrapper.

2. Should ApplicationDispatcher be able to handle any implementation of
HttpServletRequest or does J2EE-Specs allow to rely solely on own implementation
types? I ApplicationDispatcher should handle any implementation this should be
considered as a bug and the unwrap-method should be fixed!

Wolfgang

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 41696] - ApplicationDispatcher can't handle alternative HttpRequest-Implementation on forward

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41696>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41696


william.barker@wilshire.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Additional Comments From william.barker@wilshire.com  2007-05-20 13:59 -------
This is a feature, done this way exactly to support your use case.  The 
servlet spec explicitly forbids using a custom ServletRequest that is not 
derived from ServletRequestWrapper.  For the case with a Wrapper, you simply 
need to delay setting up your map:

  public String getParameter(String name) {
    if(myMap == null) {
       loadMap();
    }
    return (String)myMap.get(name);
  }

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org