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
