In 3.3, executing a forward removes the "javax.servlet.include.servlet_path" attribute. It's just one of the very many places that 3.3.x and Catalina are different. :-) In the 3.3.x nightly, all of your examples work as expected.
----- Original Message ----- From: "Andreas Junghans" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 1:35 AM Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators StaticInterceptor.java > Hi Bill, > > I'm afraid your commit won't solve the problem. As stated in the original > bug report, the problem occurs when the "javax.servlet.include.servlet_path" > attribute is _present_. I've never looked at the 3.3 source, but it seems > you only changed a case when the attribute is _not_ present. > > Let me quickly repeat the problem: > > /jsp/including.jsp --- includes ---> /jsp/test.jsp --- forwards to ---> > /html/test.html > > 1. When doing the forward, "javax.servlet.include.servlet_path" is set to > "/jsp/test.jsp" (which is the correct behaviour). > 2. Tomcat determines that "/html/test.html" is a static resource (also > correct). > 3. When serving the content, Tomcat determines the file to serve by first > looking at "javax.servlet.include.servlet_path" and _only if this is not > present_ calling getServletPath. > > The result is that Tomcat (at least 4.x) serves /jsp/test.jsp as a static > resource (which it isn't). I still think the only way to reliably solve this > problem is to introduce an additional request attribute (please look at my > bugreport for details). Otherwise, you can never be sure that deeply nested > include/forward calls are handled correctly. > > I beliebe this is a serious issue and deserves a quick - but not dirty ;-) - > fix. As said before, I'll happily supply a patch (with some help, I could > also do it for 3.3). However, since my proposed solution would require a lot > of files to be changed, I'd first like some opinions. Could the 4.x guys > please look at it? I know it's a lot to read, but the problem and proposed > fix are too complex to explain in just a few lines. > > Best regards > > Andreas Junghans > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
