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=22013>. 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=22013 RequestDispatcher.forward doesn't work with a relative path on a forwarded request ------- Additional Comments From [EMAIL PROTECTED] 2003-07-31 12:37 ------- After looking at the Servlet specification and the source code, here is what I have found : According to the specs (SRV.8.1 page 55): "To allow RequestDispatcher objects to be obtained using relative paths that are relative to the path of the current request (not relative to the root of the ServletContext), the following method is provided in the ServletRequest interface: getRequestDispatcher" The path of the current request is (at least, that's what CoyoteRequest does): if present, the value of the "javax.servlet.include.servlet_path" attribute (for include-dispatched requests), if not, the value of the servlet path, obtained with a getServletPath() on the request. With forwarded requests, the request is wrapped and the wrapper returns the new servlet path, when calling the getServletPath(), which seems to be a correct behaviour. But the getRequestDispatcher() is delegated to the wrapped request, which uses the "pre-forward" servlet path. This way, the path becomes relative to the first invoked servlet path and not to the last one, which uses a relative path . So, is this behavior correct or not, that is the question... When using relative paths, you (normally?) suppose that the path will be relative to the path of the current request ( obtained with the request.getServletPath() ) If you use different mappings, you know that the servlet will be accessed through one of this mappings. In such case, use relative paths at your own risk. With the current behavior, it's really difficult to use relative paths, because you can't even know to which path they will be relative ! One should admit that the specification are not very clear on multi-dispatched requests and relative paths ! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]