Bloody hell.

This bug was fixed a couple months ago and then got whacked by a late commit
to StaticInterceptor.java.  I take partial responsibility because I reviewed
that commit and missed the problem.  I'll try to get this taken care of this
evening.


> -----Original Message-----
> From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 12:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
>
>
> I use virtual hosts, but don't think that is the cause, although
> I have not
> traced this down (I will check that aswell). As I think of it, the webapp
> could simply be empty one with a web.xml like:
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
> 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";>
> <web-app>
>     <error-page>
>         <error-code>404</error-code>
>         <location>/errors/404.html</location>
>     </error-page>
> </web-app>
>
> Now, when I request any file through Tomcat, it will fail (error
> 500: Stack
> overflow). When a JSP is specified for <location>, it works fine. Tomcat
> outputs a correct message from the CM about the requested error page, but
> FileHandler outputs the originally requested path as requested file.
>
> I will set up an independent Tomcat installation and try this
> again without
> virtual hosts. If I have the time today, I will wrap up a webapp and post
> the .war file.
>
> ----- Original Message -----
> From: "Marc Saegesser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 29, 2001 8:54 PM
> Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
>
>
> > Could you please supply a sample webapp that demonstrates this?  Static
> > error pages seem to work OK for me.
> >
> > > -----Original Message-----
> > > From: Peer Heijnen [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, May 29, 2001 5:52 AM
> > > To: tomcat-dev
> > > Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2
> > >
> > >
> > > I'm using Tomcat 3.2.2 (relase) and have configured static .html files
> as
> > > error pages. We used JSP pages before, and everything was fine...
> However
> > > since we're using static files, Tomcat will enter an infinite loop and
> > > eventually crash with a stack overflow (with a good change of
> > > leaving Tomcat
> > > in a defunct state). We traced down this problem and have found a
> > > way to fix
> > > it, but I'm not sure if this is correct.
> > >
> > > All this is related to the ContextManager class:
> > >
> > > 1) Both handleStatus and handleError will call
> 'getHandlerForPath' when
> an
> > > error page was configured.
> > > 2) getHandlerForPath returns a the Handler for the error page.
> > > (since we're
> > > using static files, this will be a FileHandler). So far, so good.
> > > 3) Eventually handleStatus and handleError will do a
> > > 'errorServlet.service( req, res )' to service the error. This is
> > > were things
> > > go wrong.
> > >
> > > The problem is, that 'req' passed to the 'errorServlet.service(
> > > req, res )'
> > > call is the original request, while getHandlerForPath creates a
> > > new request
> > > internally with the error's request URI. Since the handler
> > > (FileHandler) is
> > > called with the original request URI, it will try to service a
> > > file matching
> > > that request, not the static file we configured. This, in turn, will
> cause
> > > and error and, in our case, an infinite loop.
> > >
> > > This can lead to very strange situations. For example, if an .jsp page
> > > generates an error and the error refers to an (existing)
> static file, it
> > > will actually end up showing the .jsp source file contents!
> > >
> > > The quick and dirty fix we use here is to simply add
> 'req.setRequestURI(
> > > ctx.getPath() + errorPath);' after the 'getHandlerForPath'
> calls in both
> > > handleError and handleStatus methods. I'm not really sure if we
> > > are allowed
> > > to modify the request in such a way, but error attributes are also set
> in
> > > this request and it seems to work fine for us. But this raises another
> > > question: why construct a completely new request and response in
> > > getHandlerForPath, and then throw it away?
> > >
> > > Cheers,
> > > Peer Heijnen
> >
>

Reply via email to