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=8566>.
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=8566

Filter using ServletRequestWrapper breaks RequestDispatcher.forward

           Summary: Filter using ServletRequestWrapper breaks
                    RequestDispatcher.forward
           Product: Tomcat 4
           Version: 4.0.3 Final
          Platform: PC
               URL: http://qlink.queensu.ca/~9cw4/loop-bug.zip
        OS/Version: Windows 9x
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Catalina
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


http://qlink.queensu.ca/~9cw4/loop-bug.zip contains a simple web-app that
produces the bug and implements a simple workaround.

* Problem:

When a filter uses a ServletRequestWrapper to modify the request in doFilter,
any changes made by ApplicationDispatcher will be completely ignored.

* Workaround:

When getRequest is called on the wrapper, its getServletPath reverts to calling
super.getServletPath(). This works correctly in 4.0.3, but could be broken
easily in future versions.

* Context:

In org.apache.catalina.core.ApplicationDispatcher:

doForward(request, response) calls wrapRequest for HTTP path-based forwards.

wrapRequest walks up the request chain past any ServletRequestWrappers and
inserts a new ApplicationHttpRequest before the first wrapper, this new request
is returned.

doForward modifies the returned request to match the target of the forward.

* Discussion:

Why does the insertion need to take place before the first ServletRequestWrapper? 

Considering the JSP spec specifically talks about using ServletRequestWrapper in
a Filter to redirect requests, it breaking forward is a serious problem.
Removing the chain walking code would seem to be the obvious fix, but I am
worried about breaking includes or other behavior.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to