I used a request dispatcher to include another servlet today and for the life of me couldn't figure out why it wouldn't dispatch to the correct place. Then I noticed that the request object in the included servlet returned the path for the original servlet, not the included servlet. What the heck? At first I thought the container implementor made a mistake, but then I checked the servlet spec. According to the spec., included servlets can get their path (servlet path, path info, etc.) from request attributes. For example, if you're included, not called directly, you must call HttpServletRequest.getAttribute("...") instead of HttpServletRequest.getServletPath(). Your servlet has to know whether or not it's included and look up the path accordingly. Whose bright ideas was that? This breaks servlets such as Struts and WebWork that dispatch to actions based on the path. getServletPath() should return the current servlet's path. If you need the path of the servlet that included you, the servlet API should provide a chain of requests. I worked around the issue by wrapping the request object I pass to the dispatcher and overridding getServletPath(), getPathInfo(), etc., to return the values for the included servlet instead of the including servlet. Thankfully WebWork insulates me from this insanity most of the time.