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

           Summary: RequestDispatcher forward not handling a
                    ServletRequestWrapper correctly when updating forward
                    request params
           Product: Tomcat 5
           Version: 5.0.28
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Servlet & JSP API
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: [EMAIL PROTECTED]


Tomcats implementation of RequestDispatcher forward not handling a 
ServletRequestWrapper correctly when updating forward request params.
Seems to modify the value of the javax.servlet.forward.request_uri
request attribute incorrectly, according to servlet spec SRV.8.4.2.

Here are some specifics, at least with version 5.0.28.

Stepping through the Tomcat source in the debugger, it
appears that the request's requestURI field gets stomped
on in the forward method of the RequestDispatcher
(ApplicationDispatcher.doForward()). I'm not sure Tomcat 
is handling a ServletRequestWrapper correctly.

I gather the servlet spec says that users may wrap the
request/response objects with their own implementation.

Tomcat's ApplicationDispatcher gets the request from
the outer request (the ServletRequestWrapper), trying to
keep track of the previous wrapper and current wrapper
(or request) as it loops through to get the real request.
With a single wrapper, the value of "previous" is the
same as the original outer request. Then Tomcat calls...

((ServletRequestWrapper) previous).setRequest(wrapper);

which is the same as calling setRequest(wrapper) on the
incoming request. Tomcat does not get and save the value
of the original request URI. It calls setRequestURI(path)
on the wrapper, effectively changing the request URI of the
original incoming request to the path of the forward.

Then Tomcat sets the javax.servlet.forward.request_uri
attribute by calling getRequestURI() from the original
request... but that just got modified. Implying the
javax.servlet.forward.request_uri attribute is going to
get the value of the path for the forward.

You can test this on Tomcat by using a couple JSP to. Use
a HttpServletRequestWrapper in one JSP for the forward.

First create "result.jsp" to display the desired request attribute...

<%@ page language="java" contentType="text/html;charset=UTF-8"%>
<html>
    <head>
        <title>RequestDispatcher Test</title>
    </head>
    <body>
        <h1>Forward Request URI</h1>
        javax.servlet.forward.request_uri =
        <%= request.getAttribute("javax.servlet.forward.request_uri") %>
    </body>
</html>

Create a JSP to forward without using a wrapper, "forward.jsp"...

<%
    javax.servlet.RequestDispatcher rd =
        request.getRequestDispatcher("result.jsp");
    rd.forward(request, response);
%>

and a second forward using HttpServletRequestWrapper, "wrapperforward.jsp"...

<%
    HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper(request);
    javax.servlet.RequestDispatcher rd =
        wrapper.getRequestDispatcher("result.jsp");
    rd.forward(wrapper, response);
%>

When you hit forward.jsp, the result page displays "/some-context/forward.jsp"
for the javax.servlet.forward.request_uri request attribute.
However, hit wrapperforward.jsp and the result page displays
"/some-context/result.jsp". From looking at the spec, I'd expect this 
should be "/some-context/wrapperforward.jsp".

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to