You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Peer Heijnen <pe...@asobrain.com> on 2001/05/29 12:52:15 UTC
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
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by Peer Heijnen <pe...@asobrain.com>.
Sorry, I made a mistake in my previous post. The fix we use is
'req.setServletPath( ctx.getPath() + "/" + errorPath )', and _not_
'req.setRequestURI( ctx.getPath() + errorPath )' as stated in my message.
Cheers,
Peer Heijnen
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
The fix for the first part of the problem has already been committed for
3.2.3. The other problem, what happens if your 404 error page doesn't
really exist has not been addressed yet, but I'll look into it.
Marc Saegesser
> -----Original Message-----
> From: Peter S. Heijnen [mailto:tomcat@asobrain.com]
> Sent: Friday, June 01, 2001 12:04 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
>
>
> Hmm.. In fact (in 3.2.2 atleast), it does not even matter if the
> file exists
> or not, since the FileHandler simply uses the originally
> requested file and
> StaticInterceptor. So I suppose its the same bug alltogether.
>
> If things are fixed in 3.2.3, I'm happy enough though. The dirty fix I
> posted earlier works fine for me in the mean time.
>
> > A related bug to this is a nasty stack overflow error if an error page
> that you
> > define is not found. It's pretty easy to reproduce, just add
> this to your
> > web.xml:
>
>
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by "Peter S. Heijnen" <to...@asobrain.com>.
Hmm.. In fact (in 3.2.2 atleast), it does not even matter if the file exists
or not, since the FileHandler simply uses the originally requested file and
StaticInterceptor. So I suppose its the same bug alltogether.
If things are fixed in 3.2.3, I'm happy enough though. The dirty fix I
posted earlier works fine for me in the mean time.
> A related bug to this is a nasty stack overflow error if an error page
that you
> define is not found. It's pretty easy to reproduce, just add this to your
> web.xml:
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by David Rees <db...@greenhydrant.com>.
A related bug to this is a nasty stack overflow error if an error page that you
define is not found. It's pretty easy to reproduce, just add this to your
web.xml:
<error-page>
<error-code>404</error-code>
<location>/some-nonexistant-file.jsp</location>
</error-page>
Then try to access a non-existant file. Tomcat will go into an infinite loop
until the stack overflows.
-Dave
On Wed, May 30, 2001 at 04:23:19PM -0500, Marc Saegesser wrote:
> 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:marc.saegesser@apropos.com]
> >
> > 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.
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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:marc.saegesser@apropos.com]
> Sent: Wednesday, May 30, 2001 9:38 AM
> To: tomcat-dev@jakarta.apache.org
> 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:tomcat@asobrain.com]
> > Sent: Wednesday, May 30, 2001 12:50 AM
> > To: tomcat-dev@jakarta.apache.org
> > 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" <ma...@apropos.com>
> > To: <to...@jakarta.apache.org>
> > 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:peer@asobrain.com]
> > > > 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
> > >
> >
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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:tomcat@asobrain.com]
> Sent: Wednesday, May 30, 2001 12:50 AM
> To: tomcat-dev@jakarta.apache.org
> 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" <ma...@apropos.com>
> To: <to...@jakarta.apache.org>
> 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:peer@asobrain.com]
> > > 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
> >
>
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by "Peter S. Heijnen" <to...@asobrain.com>.
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" <ma...@apropos.com>
To: <to...@jakarta.apache.org>
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:peer@asobrain.com]
> > 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
>
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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:peer@asobrain.com]
> 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