This was broken in 3.2.1 and unfortunately is still broken in 3.2.2 due to
the commit problem I mentioned earlier. Since this isn't a regression
failure and there is a work-around we'll log it as a bug and fix it in
3.2.3.
> -----Original Message-----
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 9:38 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
>
>
> 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
> > >
> >
