[BUG] servlet-mapping breaks after misrequest

[Jeff Turner <je...@socialchange.net.au>]

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>
EOF
cat > tomcatbug/date.xyz << EOF
<%@ page import="java.util.*" %> 
<%= (new java.util.Date() ).toLocaleString() %> 
EOF

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 "date.xyz" works as expected.
5) Move ~/tomcatbug to ~/tomcatbug~
6) Restart Tomcat
7) Request date.xyz. You should get the expected error:

Not Found (404)

Original request/tomcatbug/tomcat.notFoundHandler 

8) Move ~/tomcatbug~ to ~/tomcatbug
9) Request date.xyz. You'll see the raw source:

<%@ page import="java.util.*" %> 
<%= (new java.util.Date() ).toLocaleString() %> 


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


--Jeff

Re: [BUG] servlet-mapping breaks after misrequest

[Jeff Turner <je...@socialchange.net.au>]

On Sat, 11 Nov 2000, Craig R. McClanahan wrote:

> Hi Jeff,
> 
> Well, your reported behavior is definitely repeatable.  But, after analyzing
> it, my conclusion is "user error ... don't do that".
>
[snip "bug" report]
> 
> What do you think?

Fine :) I think it might be worth a FAQ entry though. I'll write one up
unless I hear any objections.

All the best,

--Jeff

> >
> > --Jeff
> >
> 
> Craig McClanahan
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 

Re: [BUG] servlet-mapping breaks after misrequest

["Craig R. McClanahan" <Cr...@eng.sun.com>]

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.

Craig


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>
> EOF
> cat > tomcatbug/date.xyz << EOF
> <%@ page import="java.util.*" %>
> <%= (new java.util.Date() ).toLocaleString() %>
> EOF
>
> 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 "date.xyz" 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
moment.

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

It now reports (correctly) that the request was for /tomcatbug/test.xyz, 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 date.xyz. 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