tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [BUG] servlet-mapping breaks after misrequest
Date Sat, 11 Nov 2000 20:23:43 GMT
Hi Jeff,

Well, your reported behavior is definitely repeatable.  But, after analyzing
it, my conclusion is "user error ... don't do that".  See the intermixed
discussion down where you take us through the steps to reproduce, to see if
you agree with me.


Jeff Turner wrote:

> Hi,
> Sorry if someone's reported this before,
> I just found a bug that affects (at least) Tomcat 3.2b3 up to 3.3dev from
> CVS. The bug lets the user see the source for files mapped to servlets
> via the <servlet-mapping> tag in web.xml. The bug usually occurs during
> development, so it shouldn't be an issue with stable production sites.
> In the WEB-INF/web.xml file, one can remap URIs to servlets. This mapping
> doesn't take place when you re-request a page that previously didn't
> exist (the "misrequest" of the subject line), and the user gets delivered
> uninterpreted source.
> The most common situation is you request a mapped page from a webapp that
> doesn't exist, realise your mistake, regenerate the webapp and request the
> page again. You'll see the page source, as the page hasn't been
> interpreted by it's associated servlet.
> To reproduce the bug:
> 1) Create a small webapp ~/tomcatbug which maps *.xyz to the JSP
> interpreter, using the following script if you like:
> #!/bin/sh
> cd ~
> mkdir -p tomcatbug/WEB-INF || exit
> cat > tomcatbug/WEB-INF/web.xml << EOF
> <web-app>
>  <servlet-mapping>
>   <servlet-name>jsp</servlet-name>
>   <url-pattern>*.xyz</url-pattern>
>  </servlet-mapping>
> </web-app>
> cat > tomcatbug/ << EOF
> <%@ page import="java.util.*" %>
> <%= (new java.util.Date() ).toLocaleString() %>
> 2) Add the "tomcatbug" context to your $TOMCAT_HOME/conf/server.xml:
> <Context path="/tomcatbug"
>   docBase="/home/jeff/tomcatbug"
>   debug="9"
>   reloadable="true"
>   trusted="false" >
> </Context>
> (modify the docBase as appropriate).
> 3) Restart Tomcat
> 4) Verify that the webapp works and "" works as expected.
> 5) Move ~/tomcatbug to ~/tomcatbug~
> 6) Restart Tomcat

Note that, at this point, you have made it impossible for Tomcat to find the
web.xml file for the "tomcatbug" application.  Therefore, the mapping of
"*.xyz" to the JSP servlet is not registered.  This will become important in a

> 7) Request You should get the expected error:
> Not Found (404)
> Original request/tomcatbug/tomcat.notFoundHandler

It now reports (correctly) that the request was for /tomcatbug/, by
the way.  This was a separate issue.

> 8) Move ~/tomcatbug~ to ~/tomcatbug

Note that Tomcat is *not* restarted at this point.  If it was, you would not
see the behavior discussed -- it would be just like step (4) above.

> 9) Request You'll see the raw source:
> <%@ page import="java.util.*" %>
> <%= (new java.util.Date() ).toLocaleString() %>

Why do we see this?  Well, remember that the "*.xyz" --> JSP servlet mapping
never got registered, because the web.xml file was not present when Tomcat was
last started.  Therefore, just like Tomcat is configured to, it serves the
content as a static file.  Because it's JSP source, that is what you see.

> Btw, it's not the JSP interpreter's fault; I originally found the bug
> mapping *.xml to the Cocoon servlet.

Conclusion:  I don't think there's anything you can do in Tomcat design to
avoid this scenario, except perhaps to have Tomcat refuse to start up if there
is a document base directory missing (as it would be in step (6) above), or if
there is a directory there but no "WEB-INF/web.xml" file.

But, either of those constraints would make it harder to just use Tomcat as a
simple, low-volume web server (like you might use PWS on a laptop, for
example).  Therefore, I'd prefer not to make that change.

What do you think?

> --Jeff

Craig McClanahan

View raw message