RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
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:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 12:04 AM To: [EMAIL PROTECTED] 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
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
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-code404/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
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
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-code404/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
Re: Problem+Fix concerning static error pages in Tomcat 3.2.2
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-code404/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:[EMAIL PROTECTED]] 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
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
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
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-code404/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
