RE: JSP source being shown (not being executed)
Michael, If you put the JSPs under the WEB-INF folder of the web app, Tomcat will be unable to serve them directly. Does that make any difference? Andy -Original Message- From: Schalk [mailto:[EMAIL PROTECTED] Sent: 08 June 2004 20:43 To: 'Tomcat Users List' Subject: RE: JSP source being shown (not being executed) If all .html files should go to this try using a filter instead. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Schalk [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 9:27 PM :: To: 'Tomcat Users List' :: Subject: RE: JSP source being shown (not being executed) :: :: I stand under correction but, it may even be that this not allowed at all or :: anymore. Try rather creating another extension for these files that you can :: map to. Probably the easiest. :: :: Kind Regards :: Schalk Neethling :: Web Developer.Designer.Programmer.President :: Volume4.Development.Multimedia.Branding :: emotionalize.conceptualize.visualize.realize :: Tel: +27125468436 :: Fax: +27125468436 :: email:[EMAIL PROTECTED] :: web: www.volume4.com :: :: This message contains information that is considered to be sensitive or :: confidential and may not be forwarded or disclosed to any other party :: without the permission of the sender. If you received this message in error, :: please notify me immediately so that I can correct and delete the original :: email. Thank you. :: :: :: -Original Message- :: :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: :: Sent: Tuesday, June 08, 2004 8:44 PM :: :: To: Tomcat Users List :: :: Subject: Re: JSP source being shown (not being executed) :: :: :: :: Actually, I'm not running Apache right now. This has something to do with :: my :: :: servlet context (*.html) not being sent to the JSP engine - it's treating :: it :: :: like regular HTML right now. Strange, since my other mappings seem to :: work :: :: fine (*.do). :: :: :: :: Michael :: :: :: :: :: :: - Original Message - :: :: From: Schalk [EMAIL PROTECTED] :: :: To: 'Tomcat Users List' [EMAIL PROTECTED] :: :: Sent: Tuesday, June 08, 2004 11:23 AM :: :: Subject: RE: JSP source being shown (not being executed) :: :: :: :: :: :: Just a thought but, if you are running both Apache and Tomcat, Apache is :: :: probably picking up the .html extension and tries to display the content :: of :: :: the file which will result in it displaying the code. :: :: :: :: Kind Regards :: :: Schalk Neethling :: :: Web Developer.Designer.Programmer.President :: :: Volume4.Development.Multimedia.Branding :: :: emotionalize.conceptualize.visualize.realize :: :: Tel: +27125468436 :: :: Fax: +27125468436 :: :: email:[EMAIL PROTECTED] :: :: web: www.volume4.com :: :: :: :: This message contains information that is considered to be sensitive or :: :: confidential and may not be forwarded or disclosed to any other party :: :: without the permission of the sender. If you received this message in :: error, :: :: please notify me immediately so that I can correct and delete the :: original :: :: email. Thank you. :: :: :: :: :: -Original Message- :: :: :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: :: :: Sent: Tuesday, June 08, 2004 7:58 PM :: :: :: To: Tomcat Users List :: :: :: Subject: JSP source being shown (not being executed) :: :: :: :: :: :: For some reason my JSP source is being shown - it's not being compiled :: :: and :: :: :: executed. It might be worthwhile mentioning that I am mapping some :: :: servlet :: :: :: context as *.html, which redirects to this jsp - but it worked in :: another :: :: :: app of mine and inside my new app it doesn't work. :: :: :: :: :: :: I'm running Tomcat 5.0.26 btw. :: :: :: :: :: :: Any input would be welcome. :: :: :: :: :: :: Michael :: :: :: :: :: :: :: :: :: - :: :: :: To unsubscribe, e-mail: tomcat-user- [EMAIL PROTECTED] :: :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: :: :: :: :: - :: :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: :: :: - :: :: To unsubscribe, e-mail: [EMAIL PROTECTED
RE: JSP source being shown (not being executed)
This may be the problem with was talked about a while back. Here are the contents of one of the e-mails: From: Asaf Barkan [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: security hole on windows/ Tomcat with JRE 1.4.2 (b28) Date: Sun, 24 Aug 2003 18:04:23 +0300 The syndrome is that when typing: http://myurl:8080/myfile.jsp%20 http://myurl:8080/myfile.jsp%20 The JSP code is delivered to the client. I have checked this on the followed platforms: Win2k server (SP3) JRE 1.4.2 (b28) IIS 5/Tomcat HTTP 1.1 connector It works but it is not consistent (could be some race case). BTW I have tried this on 1.4.2 (b2) and I could not compromise this hole. I have encountered a discussion on a similar issue with a recommendation to add the following argument to the Tomcat string: -Dsun.io.useCanonCaches=false I have tried this and it solved the problem. Can some tell me whether there are other solutions and what this parameter means ? Thanks a lot --- Annie Guo [EMAIL PROTECTED] wrote: I have seen that before with JDK not in the system path. -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 2:44 PM To: Tomcat Users List Subject: Re: JSP source being shown (not being executed) Actually, I'm not running Apache right now. This has something to do with my servlet context (*.html) not being sent to the JSP engine - it's treating it like regular HTML right now. Strange, since my other mappings seem to work fine (*.do). Michael - Original Message - From: Schalk [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 11:23 AM Subject: RE: JSP source being shown (not being executed) Just a thought but, if you are running both Apache and Tomcat, Apache is probably picking up the .html extension and tries to display the content of the file which will result in it displaying the code. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 7:58 PM :: To: Tomcat Users List :: Subject: JSP source being shown (not being executed) :: :: For some reason my JSP source is being shown - it's not being compiled and :: executed. It might be worthwhile mentioning that I am mapping some servlet :: context as *.html, which redirects to this jsp - but it worked in another :: app of mine and inside my new app it doesn't work. :: :: I'm running Tomcat 5.0.26 btw. :: :: Any input would be welcome. :: :: Michael :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = Norris Shelton Software Engineer Sun Certified Java 1.1 Programmer Appriss, Inc. ICQ# 26487421 AIM NorrisEShelton YIM norrisshelton __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP source being shown (not being executed)
For some reason my JSP source is being shown - it's not being compiled and executed. It might be worthwhile mentioning that I am mapping some servlet context as *.html, which redirects to this jsp - but it worked in another app of mine and inside my new app it doesn't work. I'm running Tomcat 5.0.26 btw. Any input would be welcome. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP source being shown (not being executed)
Just a thought but, if you are running both Apache and Tomcat, Apache is probably picking up the .html extension and tries to display the content of the file which will result in it displaying the code. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 7:58 PM :: To: Tomcat Users List :: Subject: JSP source being shown (not being executed) :: :: For some reason my JSP source is being shown - it's not being compiled and :: executed. It might be worthwhile mentioning that I am mapping some servlet :: context as *.html, which redirects to this jsp - but it worked in another :: app of mine and inside my new app it doesn't work. :: :: I'm running Tomcat 5.0.26 btw. :: :: Any input would be welcome. :: :: Michael :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP source being shown (not being executed)
Actually, I'm not running Apache right now. This has something to do with my servlet context (*.html) not being sent to the JSP engine - it's treating it like regular HTML right now. Strange, since my other mappings seem to work fine (*.do). Michael - Original Message - From: Schalk [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 11:23 AM Subject: RE: JSP source being shown (not being executed) Just a thought but, if you are running both Apache and Tomcat, Apache is probably picking up the .html extension and tries to display the content of the file which will result in it displaying the code. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 7:58 PM :: To: Tomcat Users List :: Subject: JSP source being shown (not being executed) :: :: For some reason my JSP source is being shown - it's not being compiled and :: executed. It might be worthwhile mentioning that I am mapping some servlet :: context as *.html, which redirects to this jsp - but it worked in another :: app of mine and inside my new app it doesn't work. :: :: I'm running Tomcat 5.0.26 btw. :: :: Any input would be welcome. :: :: Michael :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP source being shown (not being executed)
I have seen that before with JDK not in the system path. -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 2:44 PM To: Tomcat Users List Subject: Re: JSP source being shown (not being executed) Actually, I'm not running Apache right now. This has something to do with my servlet context (*.html) not being sent to the JSP engine - it's treating it like regular HTML right now. Strange, since my other mappings seem to work fine (*.do). Michael - Original Message - From: Schalk [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 11:23 AM Subject: RE: JSP source being shown (not being executed) Just a thought but, if you are running both Apache and Tomcat, Apache is probably picking up the .html extension and tries to display the content of the file which will result in it displaying the code. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 7:58 PM :: To: Tomcat Users List :: Subject: JSP source being shown (not being executed) :: :: For some reason my JSP source is being shown - it's not being compiled and :: executed. It might be worthwhile mentioning that I am mapping some servlet :: context as *.html, which redirects to this jsp - but it worked in another :: app of mine and inside my new app it doesn't work. :: :: I'm running Tomcat 5.0.26 btw. :: :: Any input would be welcome. :: :: Michael :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP source being shown (not being executed)
Thanks for your input - but this would cause any other JSP not to work either. The servlets which are mapped to *.do seem to work fine - but the one mapped to *.html isn't. Michael - Original Message - From: Annie Guo [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 11:50 AM Subject: RE: JSP source being shown (not being executed) I have seen that before with JDK not in the system path. -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 2:44 PM To: Tomcat Users List Subject: Re: JSP source being shown (not being executed) Actually, I'm not running Apache right now. This has something to do with my servlet context (*.html) not being sent to the JSP engine - it's treating it like regular HTML right now. Strange, since my other mappings seem to work fine (*.do). Michael - Original Message - From: Schalk [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, June 08, 2004 11:23 AM Subject: RE: JSP source being shown (not being executed) Just a thought but, if you are running both Apache and Tomcat, Apache is probably picking up the .html extension and tries to display the content of the file which will result in it displaying the code. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 7:58 PM :: To: Tomcat Users List :: Subject: JSP source being shown (not being executed) :: :: For some reason my JSP source is being shown - it's not being compiled and :: executed. It might be worthwhile mentioning that I am mapping some servlet :: context as *.html, which redirects to this jsp - but it worked in another :: app of mine and inside my new app it doesn't work. :: :: I'm running Tomcat 5.0.26 btw. :: :: Any input would be welcome. :: :: Michael :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP source being shown (not being executed)
I stand under correction but, it may even be that this not allowed at all or anymore. Try rather creating another extension for these files that you can map to. Probably the easiest. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 8:44 PM :: To: Tomcat Users List :: Subject: Re: JSP source being shown (not being executed) :: :: Actually, I'm not running Apache right now. This has something to do with my :: servlet context (*.html) not being sent to the JSP engine - it's treating it :: like regular HTML right now. Strange, since my other mappings seem to work :: fine (*.do). :: :: Michael :: :: :: - Original Message - :: From: Schalk [EMAIL PROTECTED] :: To: 'Tomcat Users List' [EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 11:23 AM :: Subject: RE: JSP source being shown (not being executed) :: :: :: Just a thought but, if you are running both Apache and Tomcat, Apache is :: probably picking up the .html extension and tries to display the content of :: the file which will result in it displaying the code. :: :: Kind Regards :: Schalk Neethling :: Web Developer.Designer.Programmer.President :: Volume4.Development.Multimedia.Branding :: emotionalize.conceptualize.visualize.realize :: Tel: +27125468436 :: Fax: +27125468436 :: email:[EMAIL PROTECTED] :: web: www.volume4.com :: :: This message contains information that is considered to be sensitive or :: confidential and may not be forwarded or disclosed to any other party :: without the permission of the sender. If you received this message in error, :: please notify me immediately so that I can correct and delete the original :: email. Thank you. :: :: :: -Original Message- :: :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: :: Sent: Tuesday, June 08, 2004 7:58 PM :: :: To: Tomcat Users List :: :: Subject: JSP source being shown (not being executed) :: :: :: :: For some reason my JSP source is being shown - it's not being compiled :: and :: :: executed. It might be worthwhile mentioning that I am mapping some :: servlet :: :: context as *.html, which redirects to this jsp - but it worked in another :: :: app of mine and inside my new app it doesn't work. :: :: :: :: I'm running Tomcat 5.0.26 btw. :: :: :: :: Any input would be welcome. :: :: :: :: Michael :: :: :: :: :: :: - :: :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP source being shown (not being executed)
If all .html files should go to this try using a filter instead. Kind Regards Schalk Neethling Web Developer.Designer.Programmer.President Volume4.Development.Multimedia.Branding emotionalize.conceptualize.visualize.realize Tel: +27125468436 Fax: +27125468436 email:[EMAIL PROTECTED] web: www.volume4.com This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you. :: -Original Message- :: From: Schalk [mailto:[EMAIL PROTECTED] :: Sent: Tuesday, June 08, 2004 9:27 PM :: To: 'Tomcat Users List' :: Subject: RE: JSP source being shown (not being executed) :: :: I stand under correction but, it may even be that this not allowed at all or :: anymore. Try rather creating another extension for these files that you can :: map to. Probably the easiest. :: :: Kind Regards :: Schalk Neethling :: Web Developer.Designer.Programmer.President :: Volume4.Development.Multimedia.Branding :: emotionalize.conceptualize.visualize.realize :: Tel: +27125468436 :: Fax: +27125468436 :: email:[EMAIL PROTECTED] :: web: www.volume4.com :: :: This message contains information that is considered to be sensitive or :: confidential and may not be forwarded or disclosed to any other party :: without the permission of the sender. If you received this message in error, :: please notify me immediately so that I can correct and delete the original :: email. Thank you. :: :: :: -Original Message- :: :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: :: Sent: Tuesday, June 08, 2004 8:44 PM :: :: To: Tomcat Users List :: :: Subject: Re: JSP source being shown (not being executed) :: :: :: :: Actually, I'm not running Apache right now. This has something to do with :: my :: :: servlet context (*.html) not being sent to the JSP engine - it's treating :: it :: :: like regular HTML right now. Strange, since my other mappings seem to :: work :: :: fine (*.do). :: :: :: :: Michael :: :: :: :: :: :: - Original Message - :: :: From: Schalk [EMAIL PROTECTED] :: :: To: 'Tomcat Users List' [EMAIL PROTECTED] :: :: Sent: Tuesday, June 08, 2004 11:23 AM :: :: Subject: RE: JSP source being shown (not being executed) :: :: :: :: :: :: Just a thought but, if you are running both Apache and Tomcat, Apache is :: :: probably picking up the .html extension and tries to display the content :: of :: :: the file which will result in it displaying the code. :: :: :: :: Kind Regards :: :: Schalk Neethling :: :: Web Developer.Designer.Programmer.President :: :: Volume4.Development.Multimedia.Branding :: :: emotionalize.conceptualize.visualize.realize :: :: Tel: +27125468436 :: :: Fax: +27125468436 :: :: email:[EMAIL PROTECTED] :: :: web: www.volume4.com :: :: :: :: This message contains information that is considered to be sensitive or :: :: confidential and may not be forwarded or disclosed to any other party :: :: without the permission of the sender. If you received this message in :: error, :: :: please notify me immediately so that I can correct and delete the :: original :: :: email. Thank you. :: :: :: :: :: -Original Message- :: :: :: From: Michael Mehrle [mailto:[EMAIL PROTECTED] :: :: :: Sent: Tuesday, June 08, 2004 7:58 PM :: :: :: To: Tomcat Users List :: :: :: Subject: JSP source being shown (not being executed) :: :: :: :: :: :: For some reason my JSP source is being shown - it's not being compiled :: :: and :: :: :: executed. It might be worthwhile mentioning that I am mapping some :: :: servlet :: :: :: context as *.html, which redirects to this jsp - but it worked in :: another :: :: :: app of mine and inside my new app it doesn't work. :: :: :: :: :: :: I'm running Tomcat 5.0.26 btw. :: :: :: :: :: :: Any input would be welcome. :: :: :: :: :: :: Michael :: :: :: :: :: :: :: :: :: - :: :: :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: :: :: :: :: - :: :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: :: :: - :: :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: :: For additional commands, e-mail: [EMAIL PROTECTED] :: :: :: :: - :: To unsubscribe, e-mail: [EMAIL PROTECTED] :: For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mozilla showing JSP source code
Jeff Greenland wrote: I'm sure this doesn't help, but we had the same problem with the 3.x series. It went away when we upgraded to 4.x and 5.x. Yoo-hoo! Just struggled my way through setting up Tomcat 5.0.16 (never could figure out how to get mod_jk2 to work, so fell back to mod_jk). And the problem seems to have disappeared. Don't really understand how, as I mentioned in my original note if I bypass Apache and go to directly to Tomcat (3.2.3), via :8080, I didn't see the problem. That led me to conclude that Tomcat wasn't the problem. But I'm not going to argue with success. Thanks, Jeff (and all others who offered a suggestion.) Good luck, Jeff -Original Message- From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code I've tried to do due diligence on this issue, searching the archives as well as Google. I'm sure it is a common problem, but I found several questions and no definitive responses, so here goes. Our website works fine with IE, but we're having a significant problem with Mozilla (and derivatives like Galeon). I've tried various versions, including 1.5 as well as the brand new 1.6. I'm seeing this problem both from a Windows XP/2000 host and a Solaris host. I've tried Mozilla both on Windows XP clients and Mandrake Linux 9.2 i586 clients. All exhibit the same behavior. As the title says, when using Mozilla, I'll frequently see source code in the browser window. If I hit reload, in most cases, I'll see the page properly displayed (99% of the time - rarely, I'll see the source again.) We are still using Apache 1.3.27, Tomcat 3.2.3 and mod_jk 1.2.4. Here, for example, is one I can produce very regularly: === HTTP/1.1 200 Date: Tue, 20 Jan 2004 00:14:25 GMT Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 1172 html === I'm still working on getting Tomcat 5.0.19 configured with JK2, in the hopes this will magically go away, but I've having problems getting JK2 configured properly. Here are some things I've tried or noticed: (1) I first tried going directly to Tomcat, bypassing Apache (using 8080) and this works. All our pages are displayed in Mozilla without any problem. That leads me to conclude that the problem is either in Tomcat delivering the pages to Apache via mod_jk, or in Apache delivering the pages to the browser. The first seems more likely. (2) We specify no buffer clause on our page directive. On some pages, specifying buffer=64kb seems to work. Frustratingly, this solution seems to work on some pages but not others, and on some systems and not others for the same page. (3) I also tried changing the KeepAliveTimeout in Apache httpd.conf. The default value is 15. As a test, I upped it to 150. Again, this solved the problem on some pages on some clients, but not reliably or predictably. It also caused Mozilla to spin its wheels for about the whole 2 1/2 minutes. (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mozilla showing JSP source code
Getting off the topic of visible JSP source here, but ...
Note that an HTTP redirect isn't just an additional header, it also means a
different response status (302 Moved Temporarily instead of 200 OK).
I was under the impression that calling response.sendRedirect cleared the
buffer and caused the reponse to be committed, and that further attempts to
write to the response would throw an IllegalStateException. Is this not the
case?
I'm quite certain that it's not possible to do a response.sendRedirect if
any of the body has been written to the client (this results, IIRC, in
IllegalStateException: response already committed).
So does the security issue mentioned below really exist?
-john.
-Original Message-
From: Sean Utt [mailto:[EMAIL PROTECTED]
Sent: Monday, January 19, 2004 11:27 PM
To: Tomcat Users List
Subject: Re: Mozilla showing JSP source code
Hi,
I used to see this when doing a response.sendRedirect() without following it
with a return(), but didn't see jsp source, just html source. I did have a
problem with mod_jk showing .jsp source when the URI contained a // in the
path like http://dom.ain/context//file.jsp, but that sounds like a different
problem and an upgrade of mod_jk fixed that.
The redirect without return was a common problem in dreamweaver ultradev 4.
response.sendRedirect() does not terminate execution of the servlet/jsp (nor
should it), it just adds header content to the output. I.E. is being 'nice'
by painting over the html of the page that sent the redirect with the html
of the redirected page, but netscape/mozilla leaves the html from the
redirecting page in the browser. A more serious issue is that if you are
using response.sendRedirect() to send an unauthorized user to a login page,
you are sending them the content you were trying to protect, and then
telling them they need to log in to see it. Not at all secure.
Though this is an overly simplistic analogy, think of a servlet/jsp as a
dynamically loaded function being called by tomcat. This is why you can't
call system.exit() in a servlet without terminating tomcat itself. Unless
you tell the servlet to cease processing, it will happily continue doing
what it does best -- outputting html.
bottom line:
if (not authorized) {
response.sendRedirect(some location);
return; // don't bother doing anything else
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mozilla showing JSP source code
Sean Utt wrote: Hi, I used to see this when doing a response.sendRedirect() without following it with a return(), but didn't see jsp source, just html source. I did have a problem with mod_jk showing .jsp source when the URI contained a // in the path like http://dom.ain/context//file.jsp, but that sounds like a different problem and an upgrade of mod_jk fixed that. Sean, thanks for the reply. Now that you mention it, I am indeed seeing HTML source, not JSP source. We do a *pretty* good job of putting returns after our redirects, though I find an occasional missing return. On all the pages I'm investigating, sendRedirect is followed by a return. And of course there is always the problem of Tomcat not *allowing* you to put a return if the sendRedirect is the last statement on the page; you get a code not reachable on the curly brace that follows it grr. Were you able to resolve the showing of the HTML source? Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code [snip] (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mozilla showing JSP source code
Jeff Greenland wrote: I'm sure this doesn't help, but we had the same problem with the 3.x series. It went away when we upgraded to 4.x and 5.x. Thanks, I am trying to get Tomcat 5 up to see if the problem will go away, having a little trouble getting mod_jk2 configured properly. Found some examples on the web, but can't get them to work. I'll keep plugging away. Good luck, Jeff -Original Message- From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code I've tried to do due diligence on this issue, searching the archives as well as Google. I'm sure it is a common problem, but I found several questions and no definitive responses, so here goes. Our website works fine with IE, but we're having a significant problem with Mozilla (and derivatives like Galeon). I've tried various versions, including 1.5 as well as the brand new 1.6. I'm seeing this problem both from a Windows XP/2000 host and a Solaris host. I've tried Mozilla both on Windows XP clients and Mandrake Linux 9.2 i586 clients. All exhibit the same behavior. As the title says, when using Mozilla, I'll frequently see source code in the browser window. If I hit reload, in most cases, I'll see the page properly displayed (99% of the time - rarely, I'll see the source again.) We are still using Apache 1.3.27, Tomcat 3.2.3 and mod_jk 1.2.4. Here, for example, is one I can produce very regularly: === HTTP/1.1 200 Date: Tue, 20 Jan 2004 00:14:25 GMT Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 1172 html === I'm still working on getting Tomcat 5.0.19 configured with JK2, in the hopes this will magically go away, but I've having problems getting JK2 configured properly. Here are some things I've tried or noticed: (1) I first tried going directly to Tomcat, bypassing Apache (using 8080) and this works. All our pages are displayed in Mozilla without any problem. That leads me to conclude that the problem is either in Tomcat delivering the pages to Apache via mod_jk, or in Apache delivering the pages to the browser. The first seems more likely. (2) We specify no buffer clause on our page directive. On some pages, specifying buffer=64kb seems to work. Frustratingly, this solution seems to work on some pages but not others, and on some systems and not others for the same page. (3) I also tried changing the KeepAliveTimeout in Apache httpd.conf. The default value is 15. As a test, I upped it to 150. Again, this solved the problem on some pages on some clients, but not reliably or predictably. It also caused Mozilla to spin its wheels for about the whole 2 1/2 minutes. (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mozilla showing JSP source code
Hello Guy, If you have the return in the right place, you shouldn't be seeing the problem. Since the return is in an include, is it possible that the jsp including the file didn't rebuild itself? I have had problems where I needed to stop tomcat, delete the context directory from work directory where the compiled jsp's are kept by tomcat, then restart tomcat and let it recompile everything. Depending on your configuration, tomcat might not rebuild jsp's when included files are modified. Of course you might want to check ahead of time and see if the compiled version has the return in the right place. Let me know if there is anything else I can do to help. Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Guy Rouillier [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:44 AM Subject: RE: Mozilla showing JSP source code Sean Utt wrote: Hi, I used to see this when doing a response.sendRedirect() without following it with a return(), but didn't see jsp source, just html source. I did have a problem with mod_jk showing .jsp source when the URI contained a // in the path like http://dom.ain/context//file.jsp, but that sounds like a different problem and an upgrade of mod_jk fixed that. Sean, thanks for the reply. Now that you mention it, I am indeed seeing HTML source, not JSP source. We do a *pretty* good job of putting returns after our redirects, though I find an occasional missing return. On all the pages I'm investigating, sendRedirect is followed by a return. And of course there is always the problem of Tomcat not *allowing* you to put a return if the sendRedirect is the last statement on the page; you get a code not reachable on the curly brace that follows it grr. Were you able to resolve the showing of the HTML source? Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code [snip] (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mozilla showing JSP source code
I've tried to do due diligence on this issue, searching the archives as well as Google. I'm sure it is a common problem, but I found several questions and no definitive responses, so here goes. Our website works fine with IE, but we're having a significant problem with Mozilla (and derivatives like Galeon). I've tried various versions, including 1.5 as well as the brand new 1.6. I'm seeing this problem both from a Windows XP/2000 host and a Solaris host. I've tried Mozilla both on Windows XP clients and Mandrake Linux 9.2 i586 clients. All exhibit the same behavior. As the title says, when using Mozilla, I'll frequently see source code in the browser window. If I hit reload, in most cases, I'll see the page properly displayed (99% of the time - rarely, I'll see the source again.) We are still using Apache 1.3.27, Tomcat 3.2.3 and mod_jk 1.2.4. Here, for example, is one I can produce very regularly: === HTTP/1.1 200 Date: Tue, 20 Jan 2004 00:14:25 GMT Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 1172 html === I'm still working on getting Tomcat 5.0.19 configured with JK2, in the hopes this will magically go away, but I've having problems getting JK2 configured properly. Here are some things I've tried or noticed: (1) I first tried going directly to Tomcat, bypassing Apache (using :8080) and this works. All our pages are displayed in Mozilla without any problem. That leads me to conclude that the problem is either in Tomcat delivering the pages to Apache via mod_jk, or in Apache delivering the pages to the browser. The first seems more likely. (2) We specify no buffer clause on our page directive. On some pages, specifying buffer=64kb seems to work. Frustratingly, this solution seems to work on some pages but not others, and on some systems and not others for the same page. (3) I also tried changing the KeepAliveTimeout in Apache httpd.conf. The default value is 15. As a test, I upped it to 150. Again, this solved the problem on some pages on some clients, but not reliably or predictably. It also caused Mozilla to spin its wheels for about the whole 2 1/2 minutes. (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. -- Guy Rouillier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mozilla showing JSP source code
I'm sure this doesn't help, but we had the same problem with the 3.x series. It went away when we upgraded to 4.x and 5.x. Good luck, Jeff -Original Message- From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code I've tried to do due diligence on this issue, searching the archives as well as Google. I'm sure it is a common problem, but I found several questions and no definitive responses, so here goes. Our website works fine with IE, but we're having a significant problem with Mozilla (and derivatives like Galeon). I've tried various versions, including 1.5 as well as the brand new 1.6. I'm seeing this problem both from a Windows XP/2000 host and a Solaris host. I've tried Mozilla both on Windows XP clients and Mandrake Linux 9.2 i586 clients. All exhibit the same behavior. As the title says, when using Mozilla, I'll frequently see source code in the browser window. If I hit reload, in most cases, I'll see the page properly displayed (99% of the time - rarely, I'll see the source again.) We are still using Apache 1.3.27, Tomcat 3.2.3 and mod_jk 1.2.4. Here, for example, is one I can produce very regularly: === HTTP/1.1 200 Date: Tue, 20 Jan 2004 00:14:25 GMT Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html;charset=ISO-8859-1 1172 html === I'm still working on getting Tomcat 5.0.19 configured with JK2, in the hopes this will magically go away, but I've having problems getting JK2 configured properly. Here are some things I've tried or noticed: (1) I first tried going directly to Tomcat, bypassing Apache (using :8080) and this works. All our pages are displayed in Mozilla without any problem. That leads me to conclude that the problem is either in Tomcat delivering the pages to Apache via mod_jk, or in Apache delivering the pages to the browser. The first seems more likely. (2) We specify no buffer clause on our page directive. On some pages, specifying buffer=64kb seems to work. Frustratingly, this solution seems to work on some pages but not others, and on some systems and not others for the same page. (3) I also tried changing the KeepAliveTimeout in Apache httpd.conf. The default value is 15. As a test, I upped it to 150. Again, this solved the problem on some pages on some clients, but not reliably or predictably. It also caused Mozilla to spin its wheels for about the whole 2 1/2 minutes. (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. -- Guy Rouillier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mozilla showing JSP source code
Hi,
I used to see this when doing a response.sendRedirect() without following it
with a return(), but didn't see jsp source, just html source. I did have a
problem with mod_jk showing .jsp source when the URI contained a // in the
path like http://dom.ain/context//file.jsp, but that sounds like a different
problem and an upgrade of mod_jk fixed that.
The redirect without return was a common problem in dreamweaver ultradev 4.
response.sendRedirect() does not terminate execution of the servlet/jsp (nor
should it), it just adds header content to the output. I.E. is being 'nice'
by painting over the html of the page that sent the redirect with the html
of the redirected page, but netscape/mozilla leaves the html from the
redirecting page in the browser. A more serious issue is that if you are
using response.sendRedirect() to send an unauthorized user to a login page,
you are sending them the content you were trying to protect, and then
telling them they need to log in to see it. Not at all secure.
Though this is an overly simplistic analogy, think of a servlet/jsp as a
dynamically loaded function being called by tomcat. This is why you can't
call system.exit() in a servlet without terminating tomcat itself. Unless
you tell the servlet to cease processing, it will happily continue doing
what it does best -- outputting html.
bottom line:
if (not authorized) {
response.sendRedirect(some location);
return; // don't bother doing anything else
}
If you opened any jdbc connections be sure to close them before returning.
Sean
Web Solutions That Work Developing custom web solutions designed
specifically to accomplish the unique objectives of our clients. Phone
503-639-2727 Fax 503-639-0807
- Original Message -
From: Guy Rouillier [mailto:[EMAIL PROTECTED]
Sent: Monday, January 19, 2004 5:36 PM
To: Tomcat Users List
Subject: Mozilla showing JSP source code
[snip]
(4) The most reliable way to see this fail is via a redirect. This
happens most frequently on the secure half of our website (https). On
those pages, we have an authentication header at the top of each page:
%@ include file=/includes/authenheader.jspf %
Inside this file, we check some session variables, and if they don't
have the right set of values (or those values don't exist) we
response.sendRedirect() to a login page. During this redirect, I
*always* see the source for the login page - the login page has not come
up cleanly one time. This page is very small, and neither the buffer or
timeout changes help.
If anyone has any ideas on how to address this problem, I'm willing to
try anything. I really am out of ideas and don't know where to go next.
Thanks for any help.
--
Guy Rouillier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
APACHE SHOWING JSP SOURCE ONLY!
Hi i have just configured JK_MOD 1.2.3 for apache2.0.48 with Tomcat 4.1.29 on RH 9.0. When i run my web apps from apache i get to see the source code of JSP instead of the JSP page itself. How do i fix this? regards suneel
JSP source compilation error
Using tomcat 4.1.18 I get the following error when trying to view my JSP page: An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file F:\Program Files\jakarta-tomcat-4.1.18\jakarta-tomcat-4.1.18\work\Standalone\localhost\lul\BrowseTop_jsp.java:168: handlePageException(java.lang.Exception) in javax.servlet.jsp.PageContext cannot be applied to (java.lang.Throwable) if (pageContext != null) pageContext.handlePageException(t); ^ 1 error at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530) at java.lang.Thread.run(Thread.java:536) Is there a way to fix the generated code problem without having to manually edit every source file with the error? There must be a way. _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP source compilation error
http://jakarta.apache.org/tomcat/faq/misc.html#compile -Tim Joe McGranaghan wrote: Using tomcat 4.1.18 I get the following error when trying to view my JSP page: An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file F:\Program Files\jakarta-tomcat-4.1.18\jakarta-tomcat-4.1.18\work\Standalone\localhost\lul\BrowseTop_jsp.java:168: handlePageException(java.lang.Exception) in javax.servlet.jsp.PageContext cannot be applied to (java.lang.Throwable) if (pageContext != null) pageContext.handlePageException(t); ^ 1 error at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530) at java.lang.Thread.run(Thread.java:536) Is there a way to fix the generated code problem without having to manually edit every source file with the error? There must be a way. _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSP source compilation error
Thanks for your help Tim. From: Tim Funk [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: JSP source compilation error Date: Sun, 06 Jul 2003 12:02:34 -0400 http://jakarta.apache.org/tomcat/faq/misc.html#compile -Tim Joe McGranaghan wrote: Using tomcat 4.1.18 I get the following error when trying to view my JSP page: An error occurred at line: -1 in the jsp file: null Generated servlet error: [javac] Compiling 1 source file F:\Program Files\jakarta-tomcat-4.1.18\jakarta-tomcat-4.1.18\work\Standalone\localhost\lul\BrowseTop_jsp.java:168: handlePageException(java.lang.Exception) in javax.servlet.jsp.PageContext cannot be applied to (java.lang.Throwable) if (pageContext != null) pageContext.handlePageException(t); ^ 1 error at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:130) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:293) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:340) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:352) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:474) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:184) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:865) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530) at java.lang.Thread.run(Thread.java:536) Is there a way to fix the generated code problem without having to manually edit every source file with the error? There must be a way. _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos
Using a different java.io.Reader to load JSP source
Hi there, is there a official way to change the source of a JSP page from a regular JSP file to a String read from a database? I think that Jasper uses a subclass of java.io.Reader to read the file (org.apache.jasper.compiler.JspReader) - so maybe there's a way to use a java.io.StringReader instead? Thanks, Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSP source
Sorry for asking some dumb question. I'm not a unix person. What is wget and sendmail? I cannot see those commands in UNIX. Thanks Deepa -Original Message- From: Will Hartung [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 1:43 AM To: Tomcat Users List Subject: Re: JSP source From: Bodycombe, Andrew [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: JSP source Fetching the HTML is straightforward. Just create a URL connection and read the data from the stream. Yup, great idea Andy, but too much work. Stick this in your cron tab #!/bin/sh wget -O - http://your.server.com/report.jsp?param1=xyzparam2=abc | sendmail [EMAIL PROTECTED] P.S. -O - option of wget streams the output to stdout, sendmail does the rest P.P.S. I can't even spell 'sendmail', so this may do some really horrble thing, but it's the right approach and a good start. Have fun! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
Google is your friend: http://www.google.com/search?q=wget http://www.google.com/search?q=sendmail -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 10:29 AM To: Tomcat Users List Subject: RE: JSP source Sorry for asking some dumb question. I'm not a unix person. What is wget and sendmail? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
wget is a text-based client that can make HTTP and FTP requests, copying the results to a file. It's not a browser...it doesn't show anything on the screen but a progress message. So, if there was a file somewhere that you wanted, like the latest binary release of Tomcat, you could type something like: wget http://some.mirror.com/tomcat-binary.gz and that file would be stored in the local directory on your system. No need for a browser, no need for a GUI, etc. Sendmail is a MTA (mail transport agent). Probably 2/3 or more of the electronic mail sent on the Internet is sent using sendmail at one point or another. You normally don't access it from the command line (its a service). It normally listens on port 25, and is normally installed by default on most recent versions of UNIX/Linux. John -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 4:29 AM To: Tomcat Users List Subject: RE: JSP source Sorry for asking some dumb question. I'm not a unix person. What is wget and sendmail? I cannot see those commands in UNIX. Thanks Deepa -Original Message- From: Will Hartung [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 1:43 AM To: Tomcat Users List Subject: Re: JSP source From: Bodycombe, Andrew [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: JSP source Fetching the HTML is straightforward. Just create a URL connection and read the data from the stream. Yup, great idea Andy, but too much work. Stick this in your cron tab #!/bin/sh wget -O - http://your.server.com/report.jsp?param1=xyzparam2=abc | sendmail [EMAIL PROTECTED] P.S. -O - option of wget streams the output to stdout, sendmail does the rest P.P.S. I can't even spell 'sendmail', so this may do some really horrble thing, but it's the right approach and a good start. Have fun! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions This is probably not what you want to hear, but if I had to do this, then I would be looking to provide the report data as XML and then use an XSLT stylesheet (call it your template if you wish) to transform the XML data into HTML or whatever I wanted. Regards Roger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP source
From: Turner, John [EMAIL PROTECTED] Sent: Friday, January 10, 2003 5:08 AM Subject: RE: JSP source wget is a text-based client that can make HTTP and FTP requests, copying the results to a file. wget is a popular program, but may not be installed on your system, so you'll need to hunt it down (and it is also merely an example, there are a plethora of perl, python, ruby, etc scripts that will simply fetch a URL -- those are all viable as well). Sendmail is a MTA (mail transport agent). Probably 2/3 or more of the electronic mail sent on the Internet is sent using sendmail at one point or another. Sendmail is also, essentially ubitquitous on UNIX systems. Pretty much every UNIX system (or variant) in the past 10 years has Sendmail as their default mailing system (I dunno about SCO, SCO always did things kind of strange, but ...). Now, to be fair, while your system MAY have sendmail, it may not be the current system in place, as it is also often replaced for assorted reasons by other mail systems. Also, sendmail may simply not be on your default path. I'm sure you'll hate me for this, but Contact your System Administrator for details. (Whenever I read that in a document, it's usually ME who's the Sys Adm, and it usually means I have a lot more digging to do.) However, the real point is that you are certainly welcome to write the entire thing in Java. Java is more than adequate to the task, it's not terribly difficult to do, and I'm confident you can find cut paste code around the net. However, it is also worthwhile to look at potential alternatives that make these kinds of things easier to do. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP source
Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions Thanks deepa
RE: JSP source
If you combine #3 and #4, your problem is solved. Format the details as a report...how would you format them if not HTML? All you have to do is stream the HTML into a buffer, then send that out as the body of a message. You'll want to set the ContentType on your message to HTML. You could do all of this from a JSP, but why would you want to? A cron job can call java and execute a class. If, on the other hand, you are saying that you already have a JSP that generates the report to a browser, and you want to sent that output to someone as an email message, that's different. John -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:30 AM To: [EMAIL PROTECTED] Subject: JSP source Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions Thanks deepa -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
Hi John With JSP it is like a template and I need not worry about placing the content within the template. that is the only reason for me to use a JSP. We have some applications already running Apache - Tomcat and adding a JSP is not going to be difficult Also with JSP I can alter the format very easily Please feel free to point out if I'm wrong. how could I get the html source? Could you please explain it for me. Thanks Deepa -Original Message- From: Turner, John [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:02 PM To: 'Tomcat Users List' Subject: RE: JSP source If you combine #3 and #4, your problem is solved. Format the details as a report...how would you format them if not HTML? All you have to do is stream the HTML into a buffer, then send that out as the body of a message. You'll want to set the ContentType on your message to HTML. You could do all of this from a JSP, but why would you want to? A cron job can call java and execute a class. If, on the other hand, you are saying that you already have a JSP that generates the report to a browser, and you want to sent that output to someone as an email message, that's different. John -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:30 AM To: [EMAIL PROTECTED] Subject: JSP source Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions Thanks deepa -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
Fetching the HTML is straightforward. Just create a URL connection and read the data from the stream. You could try the following: 1. Implement your report as a JSP or Servlet 2. Write an email component that acts as a client to this servlet which a) opens a URL connection to your servlet b) reads the HTML c) mails it to the intended recipients. 3. Write a cron job to run your email component Andy -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: 09 January 2003 15:43 To: Tomcat Users List Subject: RE: JSP source Hi John With JSP it is like a template and I need not worry about placing the content within the template. that is the only reason for me to use a JSP. We have some applications already running Apache - Tomcat and adding a JSP is not going to be difficult Also with JSP I can alter the format very easily Please feel free to point out if I'm wrong. how could I get the html source? Could you please explain it for me. Thanks Deepa -Original Message- From: Turner, John [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:02 PM To: 'Tomcat Users List' Subject: RE: JSP source If you combine #3 and #4, your problem is solved. Format the details as a report...how would you format them if not HTML? All you have to do is stream the HTML into a buffer, then send that out as the body of a message. You'll want to set the ContentType on your message to HTML. You could do all of this from a JSP, but why would you want to? A cron job can call java and execute a class. If, on the other hand, you are saying that you already have a JSP that generates the report to a browser, and you want to sent that output to someone as an email message, that's different. John -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:30 AM To: [EMAIL PROTECTED] Subject: JSP source Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions Thanks deepa -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: JSP source
Exactly. Something like java.net.URLConnection.getContent(), I believe. John -Original Message- From: Bodycombe, Andrew [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 10:48 AM To: 'Tomcat Users List' Subject: RE: JSP source Fetching the HTML is straightforward. Just create a URL connection and read the data from the stream. You could try the following: 1. Implement your report as a JSP or Servlet 2. Write an email component that acts as a client to this servlet which a) opens a URL connection to your servlet b) reads the HTML c) mails it to the intended recipients. 3. Write a cron job to run your email component Andy -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: 09 January 2003 15:43 To: Tomcat Users List Subject: RE: JSP source Hi John With JSP it is like a template and I need not worry about placing the content within the template. that is the only reason for me to use a JSP. We have some applications already running Apache - Tomcat and adding a JSP is not going to be difficult Also with JSP I can alter the format very easily Please feel free to point out if I'm wrong. how could I get the html source? Could you please explain it for me. Thanks Deepa -Original Message- From: Turner, John [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:02 PM To: 'Tomcat Users List' Subject: RE: JSP source If you combine #3 and #4, your problem is solved. Format the details as a report...how would you format them if not HTML? All you have to do is stream the HTML into a buffer, then send that out as the body of a message. You'll want to set the ContentType on your message to HTML. You could do all of this from a JSP, but why would you want to? A cron job can call java and execute a class. If, on the other hand, you are saying that you already have a JSP that generates the report to a browser, and you want to sent that output to someone as an email message, that's different. John -Original Message- From: Deepa Raja [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 8:30 AM To: [EMAIL PROTECTED] Subject: JSP source Hi I want to do some reporting that is to be called by a cron job. I do not want to use a reporting tool. Can use JSP * to talk to the database * fetch the relevant details * format the details as a report * fetch the HTML source of the generated report * and email it to intended recipients My doubt is is it possible to fetch the HTML source of a JSP? I know I could use java mail to email if I could manage to get the source. Please pour in your suggestions Thanks deepa -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP source
From: Bodycombe, Andrew [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: JSP source Fetching the HTML is straightforward. Just create a URL connection and read the data from the stream. Yup, great idea Andy, but too much work. Stick this in your cron tab #!/bin/sh wget -O - http://your.server.com/report.jsp?param1=xyzparam2=abc | sendmail [EMAIL PROTECTED] P.S. -O - option of wget streams the output to stdout, sendmail does the rest P.P.S. I can't even spell 'sendmail', so this may do some really horrble thing, but it's the right approach and a good start. Have fun! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability;Apache Tomcat 4.0.6 released
A security vulnerability has been confirmed to exist in Apache Tomcat 4.0.x releases (including Tomcat 4.0.5), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. This is based on a variant of the exploit that was disclosed on 09/24/2002. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. Who is vulnerable - - All Tomcat 4.0.x releases, except those in which the invoker servlet is disabled (this is not the default setting). - All Tomcat 4.1.x releases before 4.1.12, except those in which the invoker servlet is disabled (this is not the default setting), as well as 4.1.12 if and only if the invoker servlet has been enabled. The default Tomcat 4.1.12 installation is not vulnerable. Fixes and workarounds - Doing either of the following will resolve the security problem: A) Disabling the invoker servlet In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping B) If running any Tomcat 4.0.x releases, download and install the following binary patch: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/bin/hotfix/13365.zip Simply unzip the archive in the $CATALINA_HOME folder (on Windows %CATALINA_HOME%). Make sure paths are preserved when unzipping. The patch will overwrite the default webapp configuration file ($CATALINA_HOME/conf/web.xml) to add a workaround to protect against the security vulnerability. C) If running Tomcat 4.1.12 and the invoker servlet was enabled, it must be disabled at this time. A new Tomcat 4.1.x release incorporating the fix to the invoker servlet will be made available shortly. D) If running any Tomcat 4.0.x release, download and install Tomcat 4.0.6. New release --- The Apache Tomcat Team announces the immediate availability of a new release which includes a fix to the invoker servlet. Apache Tomcat 4.0.6: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.6/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP Source visible with mod_jk
Could you send us your httpd.conf and workers.properties setup ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: JSP Source visible with mod_jk
Found my error (in the last 5 min) I had a DocumentRoot /opt/jakarta-tomcat-4.0.3/webapps/mywebapp Line in my httpd.conf. No wonder that all my static source pages where delivered. Thank you for your help. Holger -Ursprüngliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 3. Oktober 2002 14:23 An: [EMAIL PROTECTED] Betreff: Re: JSP Source visible with mod_jk Could you send us your httpd.conf and workers.properties setup ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP Source visible with mod_jk
Hi, I have an application run on a TC 4.0.5 and Apache 1.3.20 with mod_jk with a ajp13 Connector. Let's say i have an url http://www.mydomain.com/mydir/index.jsp. When i enter http://www.mydomain.com/mydir/index i got the source code of this jsp. If read the security updates on http://jakarta.apache.org/site/news.html but my trouble is still there. Any idea? regs, Holger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Carrie Salazar wrote: I did see my JSP source whe I tried this bug (Tomcat 4.0.4/Apache 2.0.40). I just deleted my JKMount to servlet and mapped only the applications being used as mentioned in this group and now I can no longer see my JSP source with this method. I'll eventually move to Tomcat 4.0.5 but I wanted to apply some security immediately. Yes, you can remove the sevlet invoker mapping as I noted in the email on the security issue or on the Jakarta website news post. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Maybe I don't understand, but DefaultServlet, which is supposed to serve static content is disabled... How are we supposed to serve up pictures, etc that are static?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
The DefaultServlet is ok. But is was being called by the invoker servlet in a roundabout (unintended manner). The invoker servlet is typically mapped to /servlet/* The invoker servlet should be disabled. Or restricted using many of the ways described in other threads. You should be fine allowing the DefaultServlet to work. Adam Greene wrote: Maybe I don't understand, but DefaultServlet, which is supposed to serve static content is disabled... How are we supposed to serve up pictures, etc that are static?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
The servlet to be disabled is the invoker servlet, not the DefaultServlet. The reason you see DefaultServlet so much in these postings is that the DefaultServlet can be tricked into serving the sources of your jsp's by invoking it over the invoker servlet, thereby treating jsp's like static content. But the trouble is originating in the invoker servlet. Andreas Mohrig -Original Message- From: Adam Greene [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 2:47 PM To: Tomcat Users List Subject: Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability Maybe I don't understand, but DefaultServlet, which is supposed to serve static content is disabled... How are we supposed to serve up pictures, etc that are static?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Thu, 26 Sep 2002, Andreas Mohrig wrote: The servlet to be disabled is the invoker servlet, not the DefaultServlet. The reason you see DefaultServlet so much in these postings is that the DefaultServlet can be tricked into serving the sources of your jsp's by invoking it over the invoker servlet, thereby treating jsp's like static content. But the trouble is originating in the invoker servlet. Right. And to add a bit of perhaps clarifying information, invoking in this context means calling a servlet using a URL of the form: http://www.domain.com/context/servlet/full.class.name.of.servlet that is, /servlet is a virtual directory that invokes the invoker servlet, and full.class.name.of.servlet includes the package and class name of the servlet class. This was the main/only way of calling servlets way back when, but now the favored way is to define servlets in web.xml. And some say this invoking method of calling servlets should be disabled as a security precaution anyway, and only defined servlets should be allowed (i.e., even before this bug showed up). This is all controlled by a servlet definition and mapping in the web.xml (in Tomcat 4.0.X, at least, and I assume 4.1.X as well) -- look for invoker in it. -Original Message- From: Adam Greene [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 2:47 PM To: Tomcat Users List Subject: Questions about [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability Maybe I don't understand, but DefaultServlet, which is supposed to serve static content is disabled... How are we supposed to serve up pictures, etc that are static?? Milt Epstein Research Programmer Integration and Software Engineering (ISE) Campus Information Technologies and Educational Services (CITES) University of Illinois at Urbana-Champaign (UIUC) [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jsp source disclosure patch for legacy type 1 architectures
Your solution looks good too, and yes, one would need to be able to catalog all their /servlet/ uses, make servlet mapping entries in the web.xml, then change all code that uses those servlets to use the mapped name instead. Well what I was suggesting was to map them to the same name that they're already being invoked with. So you wouldn't have to change the code that uses them. Assuming that my suggestion actually works the way I think it should. :-) It looks like you're right: the fix for this issue is incomplete. It assumes that you were using the full class name of the servlet, and not the servlet name. So http://www.mycompany.com/myapp/servlet/org.apache.catalina.servlets.Defa ultServlet/some.jsp is no longer vulnerable, but http://www.mycompany.com/myapp/servlet/default/some.jsp is! On the other hand, the thing you posted to jguru has the opposite problem. You'll need to add a second servlet mapping to the source disclosure blocker for /servlet/org.apache.catalina.servlets.DefaultServlet/* -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Brad Plies [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 7:26 PM To: Tomcat Users List Subject: RE: Jsp source disclosure patch for legacy type 1 architectures Thanks for the reply Tim, I had downloaded and installed Apache Tomcat 4.1.12 (link on the news page), and tested it using the same server webapp config, and the vulnerability still existed. Maybe I shouldn't have recycled the server configs, but it still got through. Your solution looks good too, and yes, one would need to be able to catalog all their /servlet/ uses, make servlet mapping entries in the web.xml, then change all code that uses those servlets to use the mapped name instead. I guess the solution I offered is independent of any webapp, and works on the server config level. Thanks for the idea, I think I will try yours because it is more explicit elegant on the webapp level. Thanks again! --- Tim Moore [EMAIL PROTECTED] wrote: They also changed the InvokerServlet so that it can't be used to invoke other built-in servlets (including the DefaultServlet). So even if you uncomment the invoker servlet, you still won't be vulnerable to this specific exploit. There might be other ways in which your site is vulnerable to invoker servlet exploits, however. It's best to try to disable it if possible. One thing that might work (though I haven't tried it) is to explicitly map your servlets to the names they would be invoked as. For example, if you have a servlet com.mycompany.MyServlet that you were invoking as: http://www.mycompany.com/myapp/servlet/com.mycompany.MyServlet you should be able to add this to your myapp's web.xml: servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.MyServlet/servlet-class /servlet ... servlet-mapping servlet-nameMyServlet/servlet-name url-pattern/servlet/com.mycompany.MyServlet/url-pattern /servlet-mapping and repeat that for all of the other servlets you use. I think this would do the trick and you could then disable the invoker servlet. But, as I said, I haven't actually tried this, and obviously you would need to be able to catalog all of the servlets that your application was using. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Brad Plies [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 6:53 PM To: [EMAIL PROTECTED] Subject: Jsp source disclosure patch for legacy type 1 architectures I am not sure about the process of offering patches workarounds, but anyway, according to http://jakarta.apache.org/site/news.html#0924.1 the latest patch is actually only a disabling of the Invoker servlet. However some people with old code that who are relying on the Invoker servlet and cannot disable it w/o breaking their site are still exposed. I have posted my own custom hack to solve this problem, and it can be found here 1004251= 1004251 Someone please gently correct me with any mistakes I have made, I'm just trying to be helpful here. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jsp source disclosure patch for legacy type 1 architectures
Good eye! On the other hand, the thing you posted to jguru has the opposite problem. You'll need to add a second servlet mapping to the source disclosure blocker for /servlet/org.apache.catalina.servlets.DefaultServlet/ __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP source code exposure in Tomcat 4.x
3.2 Workaround: There are at least two ways to protect from this vulnerability. A. Tomcat in tandem with HTTP server front-end: If you are using front-end HTTP server you can filter all requests with the pattern */servlet/org.apache.catalina.servlets.DefaultServlet* b. If you are using mod_jk to connect tomcat to you front-end server map to Tomcat only the URL's that are part from you application but not all request. See the usage of JkMount directive. Anyone can post an example of how either A or B can be done? Does it matter which method is used? -- carrie s. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
The servlets are not vulnerable since their code is under WEB-INF and is successfully protected from downloads. All other interpreted application stuff, outside of WEB-INF, like JSP are vulnerable since they can be downloaded as regular files but not be processed by the corresponding engine. That's why I believe Velocity should suffer from this bug in the same way JSP is. I didn't test Velocity but there is not any reason that it will be resistant to this exposure. Regards, Rossen Raykov -Original Message- From: Kent Perrier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:59 PM To: Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerabili ty
Anyway, using scriptlets (JSP) is a bad pratice... good code uses only taglibs. On Wed, 2002-09-25 at 10:57, Rossen Raykov wrote: The servlets are not vulnerable since their code is under WEB-INF and is successfully protected from downloads. All other interpreted application stuff, outside of WEB-INF, like JSP are vulnerable since they can be downloaded as regular files but not be processed by the corresponding engine. That's why I believe Velocity should suffer from this bug in the same way JSP is. I didn't test Velocity but there is not any reason that it will be resistant to this exposure. Regards, Rossen Raykov -Original Message- From: Kent Perrier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:59 PM To: Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Faculdade Ritter dos Reis www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303328 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
Hi. I've just confirmed that Velocity (at least in Turbine v2.1) suffers from this problem. Regards, Dan On Wed, 25 Sep 2002, Rossen Raykov wrote: The servlets are not vulnerable since their code is under WEB-INF and is successfully protected from downloads. All other interpreted application stuff, outside of WEB-INF, like JSP are vulnerable since they can be downloaded as regular files but not be processed by the corresponding engine. That's why I believe Velocity should suffer from this bug in the same way JSP is. I didn't test Velocity but there is not any reason that it will be resistant to this exposure. Regards, Rossen Raykov -Original Message- From: Kent Perrier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:59 PM To: Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerabili ty
please let me know if you are still experiencing this. It looks correct to me right now. Thanks, Rob Reed Isomedia.com On Wed, 2002-09-25 at 14:28, Dan K. wrote: Hi. I've just confirmed that Velocity (at least in Turbine v2.1) suffers from this problem. Regards, Dan On Wed, 25 Sep 2002, Rossen Raykov wrote: The servlets are not vulnerable since their code is under WEB-INF and is successfully protected from downloads. All other interpreted application stuff, outside of WEB-INF, like JSP are vulnerable since they can be downloaded as regular files but not be processed by the corresponding engine. That's why I believe Velocity should suffer from this bug in the same way JSP is. I didn't test Velocity but there is not any reason that it will be resistant to this exposure. Regards, Rossen Raykov -Original Message- From: Kent Perrier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:59 PM To: Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
I'm referring to Tomcat v4.0.4 with Turbine v2.1 on both Windows XP and Linux platforms, and yes it does suffer from the vulnerability. I've not tried the fixed versions 4.0.5 or 4.1.12 yet. Regards, Dan On 25 Sep 2002, Rob Reed wrote: please let me know if you are still experiencing this. It looks correct to me right now. Thanks, Rob Reed Isomedia.com On Wed, 2002-09-25 at 14:28, Dan K. wrote: Hi. I've just confirmed that Velocity (at least in Turbine v2.1) suffers from this problem. Regards, Dan On Wed, 25 Sep 2002, Rossen Raykov wrote: The servlets are not vulnerable since their code is under WEB-INF and is successfully protected from downloads. All other interpreted application stuff, outside of WEB-INF, like JSP are vulnerable since they can be downloaded as regular files but not be processed by the corresponding engine. That's why I believe Velocity should suffer from this bug in the same way JSP is. I didn't test Velocity but there is not any reason that it will be resistant to this exposure. Regards, Rossen Raykov -Original Message- From: Kent Perrier [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:59 PM To: Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
I tried to test this security vulnerability on my tomcat 4.0.4 (alone) setup but wasn't able to view my JSP files as claimed. According to http://online.securityfocus.com/archive/1/292936/2002-09-21/2002-09-27/0, if my JSP file is accessible via http://donor.ucsd.edu:7873/ccdb/experiment/index.jsp then I should be able to view my source. However, I tried 2 different URL (http://donor.ucsd.edu:7873/ccdb/experiment/org.apache.catalina.servlets.Default Servlet/index.jsp and http://donor.ucsd.edu:7873/org.apache.catalina.servlets.DefaultServlet/ccdb/expe riment/index.jsp) and all I got was a tomcat 404 error page. Has anyone actually been able to view their JSP source via this vulnerability? Mona == Mona Wong-Barnum National Center for Microscopy and Imaging Research University of California, San Diego http://ncmir.ucsd.edu/ The truth shall set you free, but first it will piss you off A Landmark instructor == -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
The URL would be: http://donor.ucsd.edu:7873/ccdb/servlet/org.apache.catalina.servlets.De faultServlet/experiment/index.jsp And yes you are vulnerable ;-) Broken down: /ccdb - the context path of your webapp /servlet - the path mapped to the invoker servlet **this is the dangerous part** /org.apache.catalina.servlets.DefaultServlet - used by the invoker servlet to determine what servlet class to invoke /experiment/index.jsp - the context relative path to your JSP, served statically by the DefaultServlet -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Mona Wong-Barnum [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability I tried to test this security vulnerability on my tomcat 4.0.4 (alone) setup but wasn't able to view my JSP files as claimed. According to http://online.securityfocus.com/archive/1/292936/2002-09-21/20 02-09-27/0, if my JSP file is accessible via http://donor.ucsd.edu:7873/ccdb/experiment/index.jsp then I should be able to view my source. However, I tried 2 different URL (http://donor.ucsd.edu:7873/ccdb/experiment/org.apache.catalina.servlets .Default Servlet/index.jsp and http://donor.ucsd.edu:7873/org.apache.catalina.servlets.DefaultServlet/c cdb/expe riment/index.jsp) and all I got was a tomcat 404 error page. Has anyone actually been able to view their JSP source via this vulnerability? Mona -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jsp source disclosure patch for legacy type 1 architectures
I am not sure about the process of offering patches workarounds, but anyway, according to http://jakarta.apache.org/site/news.html#0924.1 the latest patch is actually only a disabling of the Invoker servlet. However some people with old code that who are relying on the Invoker servlet and cannot disable it w/o breaking their site are still exposed. I have posted my own custom hack to solve this problem, and it can be found here http://www.jguru.com/forums/view.jsp?EID=1004251 Someone please gently correct me with any mistakes I have made, I'm just trying to be helpful here. __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jsp source disclosure patch for legacy type 1 architectures
They also changed the InvokerServlet so that it can't be used to invoke other built-in servlets (including the DefaultServlet). So even if you uncomment the invoker servlet, you still won't be vulnerable to this specific exploit. There might be other ways in which your site is vulnerable to invoker servlet exploits, however. It's best to try to disable it if possible. One thing that might work (though I haven't tried it) is to explicitly map your servlets to the names they would be invoked as. For example, if you have a servlet com.mycompany.MyServlet that you were invoking as: http://www.mycompany.com/myapp/servlet/com.mycompany.MyServlet you should be able to add this to your myapp's web.xml: servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.MyServlet/servlet-class /servlet ... servlet-mapping servlet-nameMyServlet/servlet-name url-pattern/servlet/com.mycompany.MyServlet/url-pattern /servlet-mapping and repeat that for all of the other servlets you use. I think this would do the trick and you could then disable the invoker servlet. But, as I said, I haven't actually tried this, and obviously you would need to be able to catalog all of the servlets that your application was using. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Brad Plies [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 6:53 PM To: [EMAIL PROTECTED] Subject: Jsp source disclosure patch for legacy type 1 architectures I am not sure about the process of offering patches workarounds, but anyway, according to http://jakarta.apache.org/site/news.html#0924.1 the latest patch is actually only a disabling of the Invoker servlet. However some people with old code that who are relying on the Invoker servlet and cannot disable it w/o breaking their site are still exposed. I have posted my own custom hack to solve this problem, and it can be found here http://www.jguru.com/forums/view.jsp?EID= 1004251 Someone please gently correct me with any mistakes I have made, I'm just trying to be helpful here. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jsp source disclosure patch for legacy type 1 architectures
Thanks for the reply Tim, I had downloaded and installed Apache Tomcat 4.1.12 (link on the news page), and tested it using the same server webapp config, and the vulnerability still existed. Maybe I shouldn't have recycled the server configs, but it still got through. Your solution looks good too, and yes, one would need to be able to catalog all their /servlet/ uses, make servlet mapping entries in the web.xml, then change all code that uses those servlets to use the mapped name instead. I guess the solution I offered is independent of any webapp, and works on the server config level. Thanks for the idea, I think I will try yours because it is more explicit elegant on the webapp level. Thanks again! --- Tim Moore [EMAIL PROTECTED] wrote: They also changed the InvokerServlet so that it can't be used to invoke other built-in servlets (including the DefaultServlet). So even if you uncomment the invoker servlet, you still won't be vulnerable to this specific exploit. There might be other ways in which your site is vulnerable to invoker servlet exploits, however. It's best to try to disable it if possible. One thing that might work (though I haven't tried it) is to explicitly map your servlets to the names they would be invoked as. For example, if you have a servlet com.mycompany.MyServlet that you were invoking as: http://www.mycompany.com/myapp/servlet/com.mycompany.MyServlet you should be able to add this to your myapp's web.xml: servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.MyServlet/servlet-class /servlet ... servlet-mapping servlet-nameMyServlet/servlet-name url-pattern/servlet/com.mycompany.MyServlet/url-pattern /servlet-mapping and repeat that for all of the other servlets you use. I think this would do the trick and you could then disable the invoker servlet. But, as I said, I haven't actually tried this, and obviously you would need to be able to catalog all of the servlets that your application was using. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Brad Plies [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 6:53 PM To: [EMAIL PROTECTED] Subject: Jsp source disclosure patch for legacy type 1 architectures I am not sure about the process of offering patches workarounds, but anyway, according to http://jakarta.apache.org/site/news.html#0924.1 the latest patch is actually only a disabling of the Invoker servlet. However some people with old code that who are relying on the Invoker servlet and cannot disable it w/o breaking their site are still exposed. I have posted my own custom hack to solve this problem, and it can be found here http://www.jguru.com/forums/view.jsp?EID= 1004251 Someone please gently correct me with any mistakes I have made, I'm just trying to be helpful here. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
I did see my JSP source whe I tried this bug (Tomcat 4.0.4/Apache 2.0.40). I just deleted my JKMount to servlet and mapped only the applications being used as mentioned in this group and now I can no longer see my JSP source with this method. I'll eventually move to Tomcat 4.0.5 but I wanted to apply some security immediately. -- carrie s. On Wed, Sep 25, 2002 at 03:15:31PM -0700, Mona Wong-Barnum wrote: I tried to test this security vulnerability on my tomcat 4.0.4 (alone) setup but wasn't able to view my JSP files as claimed. According to http://online.securityfocus.com/archive/1/292936/2002-09-21/2002-09-27/0, if my JSP file is accessible via http://donor.ucsd.edu:7873/ccdb/experiment/index.jsp then I should be able to view my source. However, I tried 2 different URL (http://donor.ucsd.edu:7873/ccdb/experiment/org.apache.catalina.servlets.Default Servlet/index.jsp and http://donor.ucsd.edu:7873/org.apache.catalina.servlets.DefaultServlet/ccdb/expe riment/index.jsp) and all I got was a tomcat 404 error page. Has anyone actually been able to view their JSP source via this vulnerability? Mona == Mona Wong-Barnum National Center for Microscopy and Imaging Research University of California, San Diego http://ncmir.ucsd.edu/ The truth shall set you free, but first it will piss you off A Landmark instructor == -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP source code exposure in Tomcat 4.x
Tomcat 4.x JSP source exposure security advisory
1. Summary
Tomcat 4.0.4 and 4.1.10 (probably all other earlier versions also) are
vulnerable to source code exposure by using the default servlet
org.apache.catalina.servlets.DefaultServlet.
2. Details:
Let say you have valid URL like http://my.site/login.jsp, then an URL like
http://my.site/servlet/org.apache.catalina.servlets.DefaultServlet/login.jsp
will give you the source code of the JSP page.
The full syntaxes of the exposure URL is:
http://{server}[:port]/[Context/]org.apache.catalina.servlets.DefaultServlet
/[context_relative_path/]file_name.jsp
For example to see the JSP source of Tomcat 4.1.10 admin application
http://localhost:8080/admin/index.jsp
execute
http://localhost:8080/admin/servlet/org.apache.catalina.servlets.DefaultServ
let/index.jsp
3. Solution:
3.1 Upgrade to the last releases 4.0.5 and 4.1.12
See
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ for the last
releases.
3.2 Workaround:
There are at least two ways to protect from this vulnerability.
A. Tomcat in tandem with HTTP server front-end:
a. If you are using front-end HTTP server you can filter all
requests with the pattern
*/servlet/org.apache.catalina.servlets.DefaultServlet*
b. If you are using mod_jk to connect tomcat to you
front-end server map to Tomcat only the URL's that are part from you
application but not all request. See the usage of JkMount directive.
B. If you are using standalone Tomcat then add protection for this
location in all you application descriptors - web.xml. Simple example:
security-constraint
display-nameDefault Servlet/display-name
!-- Disable direct alls on the Default Servlet/web-resource-name --
web-resource-collection
web-resource-nameDisallowed Location/web-resource-name
url-pattern/servlet/org.apache.catalina.servlets.DefaultServlet/*/url-pat
tern
http-methodDELETE/http-method
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-name/role-name
/auth-constraint
/security-constraint
See the server's documentation for more details.
Regards,
Rossen Raykov
PS. Special thanks to the Tomcat development team for their quick response.
---
Rossen Raykov
COGNICASE U.S.A. Inc.
(908) 860-1100 Ext. 1140
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP source code exposure in Tomcat 4.x
Rossen Raykov wrote: Tomcat 4.x JSP source exposure security advisory 1. Summary Tomcat 4.0.4 and 4.1.10 (probably all other earlier versions also) are vulnerable to source code exposure by using the default servlet org.apache.catalina.servlets.DefaultServlet. --= [ cut ] =-- 3. Solution: 3.1 Upgrade to the last releases 4.0.5 and 4.1.12 See http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ for the last releases. I'm a newbie to Tomcat and JSP at all, so I have a question: can this upgrade be done by using new binaries only, not by upgrading an entire distribution including configs? I don't want to overwrite my configure files, because it took some time for me to understand its structure and meaning. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP source code exposure in Tomcat 4.x
Veniamin Fichin wrote: Rossen Raykov wrote: Tomcat 4.x JSP source exposure security advisory 1. Summary Tomcat 4.0.4 and 4.1.10 (probably all other earlier versions also) are vulnerable to source code exposure by using the default servlet org.apache.catalina.servlets.DefaultServlet. --= [ cut ] =-- 3. Solution: 3.1 Upgrade to the last releases 4.0.5 and 4.1.12 See http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ for the last releases. I'm a newbie to Tomcat and JSP at all, so I have a question: can this upgrade be done by using new binaries only, not by upgrading an entire distribution including configs? I don't want to overwrite my configure files, because it took some time for me to understand its structure and meaning. No, you do not need to upgrade. Read the advisory I posted earlier, or the news item posted on the Jakarta website. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Do us, or rather me, a favor, and take your arrogant, l33t rant somewhere else. Believe me, I'm already awake. John -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:26 PM To: tomcat-dev; Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
I'm having a hard time finding many specifics about this exploit. It sounds like you're forcing the default servlet to serve up the source page as static content. Why isn't Velocity vulnerable in the same way? I'll buy that Velocity is faster than JSP, and certainly can be more concise and readable. I haven't seen much about security. What makes it more secure than JSP? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:26 PM To: tomcat-dev; Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
The problem is not connected directly to the JSPs or the jsp engine. It's the default servlet that has the problem. I didn't test it but I believe using this vulnerability one can get Velocity also. What he will find inside - depends only on the programmers/designers in both cases. Regards, Rossen -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:26 PM To: tomcat-dev; Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
See the original posting on BugTrag for more details http://online.securityfocus.com/archive/1/292936/2002-09-21/2002-09-27/0 Regards, Rossen Raykov -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:34 PM To: Tomcat Users List Subject: RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability I'm having a hard time finding many specifics about this exploit. It sounds like you're forcing the default servlet to serve up the source page as static content. Why isn't Velocity vulnerable in the same way? I'll buy that Velocity is faster than JSP, and certainly can be more concise and readable. I haven't seen much about security. What makes it more secure than JSP? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:26 PM To: tomcat-dev; Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Rossen Raykov [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:17 PM To: 'Tomcat Users List' Subject: RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability See the original posting on BugTrag for more details http://online.securityfocus.com/archive/1/292936/2002-09-21/20 02-09-27/0 Regards, Rossen Raykov -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:34 PM To: Tomcat Users List Subject: RE: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability I'm having a hard time finding many specifics about this exploit. It sounds like you're forcing the default servlet to serve up the source page as static content. Why isn't Velocity vulnerable in the same way? I'll buy that Velocity is faster than JSP, and certainly can be more concise and readable. I haven't seen much about security. What makes it more secure than JSP? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 5:26 PM To: tomcat-dev; Tomcat Users List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
On Tue, Sep 24, 2002 at 06:52:10PM -0400, Tim Moore wrote: OK, thanks. (The BugTraq search engine wasn't working when I checked there.) So it sounds pretty much like what I thought it was. I still don't understand why Velocity wouldn't be vulnerable to this exploit. It sounds to me like it should be. From the bugtraq post, all servlets and JSPs that run in a Tomcat instance are vulnerable. Since Velocity runs under Tomcat, logically, it is vulnerable. All other claims are illogical. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Webdav: how do I get to JSP source?
... or anything else tomcat modifies during retrieve? Ray Allis
Re: Tomcat, Apache: JSP source code showed instead of generated HTML
You're right, I forgot to attach the file... classic mistake. This time it's attached. Anybody else who's got an idea? Regards, Gero sorry - I'm all out of ideas. but I didn't see the mod_jk attachment, did you do a me and not attach it? (o: cheesr dim On Wed, 29 Aug 2001, Gero Vermaas wrote: OK, I cracked up the debug level and now mod_jk.log contains more info (see attacheement). The strange thing I notice is that is seems to try to execute everything twice. Does this ring a bel with anybody? The jasper.log file does not contain much more info: 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Scratch dir for the JSP engine is: /opt/jakarta-tomcat-3.2.3/work/localhost_8080%2Fexamples 2001-08-29 18:29:15 - IMPORTANT: Do not modify the generated servlets 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) Any ideas? Regards, Gero Dmitri Colebatch wrote: Hi, I remember this - didn't get it working hey? bugger... ok, two things I can suggest: 1. crank up the log level in mod_jk.conf to debug, see if it tells you anything interesting 2. have a look in jasper.log (also crank the log level up - in server.xml) and see if that contains anything interested... normally when a jsp is requested you'll be a fair bit of debug as it is compiled. hth, cheesr dim On 29 Aug 2001, Gero Vermaas wrote: Hi all! I sent mail to this mailing list a while ago stating that I could not get apache to work with tomcat... well I tried all kinds of solutions, monitored the mailing list and unfortunately I still haven?t been able to get it up and running. The problem: - Requesting a JSP page by doing a request via port 8080 works fine - Requesting a JSP page via apache and mod_jk returns the JSP source code Is seems that requests to JSPs are not directed to port 8007 of Tomcat. I try to give a concise description below, hopefully somebody can tell what I?m missing. It must be something simple... Apache version: 1.3.14 Tomcat version: 3.2.3 Mod_jk version: tomcat-mod-3.2.2-1.i386.rpm The apache error.log states the following when apache is started: [Wed Aug 29 08:59:23 2001] [notice] Apache-AdvancedExtranetServer/1.3.14 (Linux-M andrake/2mdk) mod_ssl/2.7.1 OpenSSL/0.9.5a mod_jk configured -- resuming normal o perations As you can see mod_jk is configured and seems to be fine. I started TomCat before starting apache and this Tomcat reported the following: [root@gerodt gero]# 2001-08-29 09:02:12 - Ctx( /examples ): Set debug to 1 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /examples ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /admin ) Starting tomcat. Check logs/tomcat.log for error messages 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /test ) 2001-08-29 09:02:12 - Ctx( /examples ): XmlReader - init /examples webapps/examp les 2001-08-29 09:02:12 - Ctx( /examples ): Reading /opt/jakarta-tomcat-3.2.3/webapps /examples/WEB-INF/web.xml 2001-08-29 09:02:13 - Ctx( /examples ): Add user tomcat tomcat tomcat 2001-08-29 09:02:13 - Ctx( /examples ): Add user role1 tomcat role1 2001-08-29 09:02:13 - Ctx( /examples ): Add user both tomcat tomcat,role1 2001-08-29 09:02:13 - Ctx( /examples ): Loading -2147483646 jsp 2001-08-29 09:02:13 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2001-08-29 09:02:13 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 Below I?ll include the mod_jk.conf and worker.properties file. I checked all paths in these file and they all seem to be correct. Doing a telnet to port 8007 reports: [root@gerodt gero]# telnet localhost 8007 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is ?^]?. HANDLER THREAD PROBLEM: java.io.IOException: Stream broken java.io.IOException: Stream broken at org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp12ConnectionHa ndler.java:426) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12Connect ionHandler.java:147) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) So Tomcat is accepting requests on this port. A strange this I discovered is that the /var/log/httpd/mod_jk.log file remains empty when I do a: /etc/rc.d/rc5.d/S85httpd stop followed by a /etc/rc.d/rc5.d/S85httpd start However, when I do a: /etc/rc.d/rc5.d/S85httpd restart The mod_jk.log file contains: [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t
Tomcat, Apache: JSP source code showed instead of generated HTML
Hi all! I sent mail to this mailing list a while ago stating that I could not get apache to work with tomcat... well I tried all kinds of solutions, monitored the mailing list and unfortunately I still haven?t been able to get it up and running. The problem: - Requesting a JSP page by doing a request via port 8080 works fine - Requesting a JSP page via apache and mod_jk returns the JSP source code Is seems that requests to JSPs are not directed to port 8007 of Tomcat. I try to give a concise description below, hopefully somebody can tell what I?m missing. It must be something simple... Apache version: 1.3.14 Tomcat version: 3.2.3 Mod_jk version: tomcat-mod-3.2.2-1.i386.rpm The apache error.log states the following when apache is started: [Wed Aug 29 08:59:23 2001] [notice] Apache-AdvancedExtranetServer/1.3.14 (Linux-M andrake/2mdk) mod_ssl/2.7.1 OpenSSL/0.9.5a mod_jk configured -- resuming normal o perations As you can see mod_jk is configured and seems to be fine. I started TomCat before starting apache and this Tomcat reported the following: [root@gerodt gero]# 2001-08-29 09:02:12 - Ctx( /examples ): Set debug to 1 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /examples ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /admin ) Starting tomcat. Check logs/tomcat.log for error messages 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /test ) 2001-08-29 09:02:12 - Ctx( /examples ): XmlReader - init /examples webapps/examp les 2001-08-29 09:02:12 - Ctx( /examples ): Reading /opt/jakarta-tomcat-3.2.3/webapps /examples/WEB-INF/web.xml 2001-08-29 09:02:13 - Ctx( /examples ): Add user tomcat tomcat tomcat 2001-08-29 09:02:13 - Ctx( /examples ): Add user role1 tomcat role1 2001-08-29 09:02:13 - Ctx( /examples ): Add user both tomcat tomcat,role1 2001-08-29 09:02:13 - Ctx( /examples ): Loading -2147483646 jsp 2001-08-29 09:02:13 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2001-08-29 09:02:13 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 Below I?ll include the mod_jk.conf and worker.properties file. I checked all paths in these file and they all seem to be correct. Doing a telnet to port 8007 reports: [root@gerodt gero]# telnet localhost 8007 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is ?^]?. HANDLER THREAD PROBLEM: java.io.IOException: Stream broken java.io.IOException: Stream broken at org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp12ConnectionHa ndler.java:426) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12Connect ionHandler.java:147) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) So Tomcat is accepting requests on this port. A strange this I discovered is that the /var/log/httpd/mod_jk.log file remains empty when I do a: /etc/rc.d/rc5.d/S85httpd stop followed by a /etc/rc.d/rc5.d/S85httpd start However, when I do a: /etc/rc.d/rc5.d/S85httpd restart The mod_jk.log file contains: [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t
Re: Tomcat, Apache: JSP source code showed instead of generated HTML
Hi, I remember this - didn't get it working hey? bugger... ok, two things I can suggest: 1. crank up the log level in mod_jk.conf to debug, see if it tells you anything interesting 2. have a look in jasper.log (also crank the log level up - in server.xml) and see if that contains anything interested... normally when a jsp is requested you'll be a fair bit of debug as it is compiled. hth, cheesr dim On 29 Aug 2001, Gero Vermaas wrote: Hi all! I sent mail to this mailing list a while ago stating that I could not get apache to work with tomcat... well I tried all kinds of solutions, monitored the mailing list and unfortunately I still haven?t been able to get it up and running. The problem: - Requesting a JSP page by doing a request via port 8080 works fine - Requesting a JSP page via apache and mod_jk returns the JSP source code Is seems that requests to JSPs are not directed to port 8007 of Tomcat. I try to give a concise description below, hopefully somebody can tell what I?m missing. It must be something simple... Apache version: 1.3.14 Tomcat version: 3.2.3 Mod_jk version: tomcat-mod-3.2.2-1.i386.rpm The apache error.log states the following when apache is started: [Wed Aug 29 08:59:23 2001] [notice] Apache-AdvancedExtranetServer/1.3.14 (Linux-M andrake/2mdk) mod_ssl/2.7.1 OpenSSL/0.9.5a mod_jk configured -- resuming normal o perations As you can see mod_jk is configured and seems to be fine. I started TomCat before starting apache and this Tomcat reported the following: [root@gerodt gero]# 2001-08-29 09:02:12 - Ctx( /examples ): Set debug to 1 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /examples ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /admin ) Starting tomcat. Check logs/tomcat.log for error messages 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /test ) 2001-08-29 09:02:12 - Ctx( /examples ): XmlReader - init /examples webapps/examp les 2001-08-29 09:02:12 - Ctx( /examples ): Reading /opt/jakarta-tomcat-3.2.3/webapps /examples/WEB-INF/web.xml 2001-08-29 09:02:13 - Ctx( /examples ): Add user tomcat tomcat tomcat 2001-08-29 09:02:13 - Ctx( /examples ): Add user role1 tomcat role1 2001-08-29 09:02:13 - Ctx( /examples ): Add user both tomcat tomcat,role1 2001-08-29 09:02:13 - Ctx( /examples ): Loading -2147483646 jsp 2001-08-29 09:02:13 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2001-08-29 09:02:13 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 Below I?ll include the mod_jk.conf and worker.properties file. I checked all paths in these file and they all seem to be correct. Doing a telnet to port 8007 reports: [root@gerodt gero]# telnet localhost 8007 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is ?^]?. HANDLER THREAD PROBLEM: java.io.IOException: Stream broken java.io.IOException: Stream broken at org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp12ConnectionHa ndler.java:426) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12Connect ionHandler.java:147) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) So Tomcat is accepting requests on this port. A strange this I discovered is that the /var/log/httpd/mod_jk.log file remains empty when I do a: /etc/rc.d/rc5.d/S85httpd stop followed by a /etc/rc.d/rc5.d/S85httpd start However, when I do a: /etc/rc.d/rc5.d/S85httpd restart The mod_jk.log file contains: [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185
Re: Tomcat, Apache: JSP source code showed instead of generated HTML
sorry - I'm all out of ideas. but I didn't see the mod_jk attachment, did you do a me and not attach it? (o: cheesr dim On Wed, 29 Aug 2001, Gero Vermaas wrote: OK, I cracked up the debug level and now mod_jk.log contains more info (see attacheement). The strange thing I notice is that is seems to try to execute everything twice. Does this ring a bel with anybody? The jasper.log file does not contain much more info: 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Scratch dir for the JSP engine is: /opt/jakarta-tomcat-3.2.3/work/localhost_8080%2Fexamples 2001-08-29 18:29:15 - IMPORTANT: Do not modify the generated servlets 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) 2001-08-29 18:29:15 - Parent class loader is: AdaptiveClassLoader( ) Any ideas? Regards, Gero Dmitri Colebatch wrote: Hi, I remember this - didn't get it working hey? bugger... ok, two things I can suggest: 1. crank up the log level in mod_jk.conf to debug, see if it tells you anything interesting 2. have a look in jasper.log (also crank the log level up - in server.xml) and see if that contains anything interested... normally when a jsp is requested you'll be a fair bit of debug as it is compiled. hth, cheesr dim On 29 Aug 2001, Gero Vermaas wrote: Hi all! I sent mail to this mailing list a while ago stating that I could not get apache to work with tomcat... well I tried all kinds of solutions, monitored the mailing list and unfortunately I still haven?t been able to get it up and running. The problem: - Requesting a JSP page by doing a request via port 8080 works fine - Requesting a JSP page via apache and mod_jk returns the JSP source code Is seems that requests to JSPs are not directed to port 8007 of Tomcat. I try to give a concise description below, hopefully somebody can tell what I?m missing. It must be something simple... Apache version: 1.3.14 Tomcat version: 3.2.3 Mod_jk version: tomcat-mod-3.2.2-1.i386.rpm The apache error.log states the following when apache is started: [Wed Aug 29 08:59:23 2001] [notice] Apache-AdvancedExtranetServer/1.3.14 (Linux-M andrake/2mdk) mod_ssl/2.7.1 OpenSSL/0.9.5a mod_jk configured -- resuming normal o perations As you can see mod_jk is configured and seems to be fine. I started TomCat before starting apache and this Tomcat reported the following: [root@gerodt gero]# 2001-08-29 09:02:12 - Ctx( /examples ): Set debug to 1 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /examples ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /admin ) Starting tomcat. Check logs/tomcat.log for error messages 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( ) 2001-08-29 09:02:12 - ContextManager: Adding context Ctx( /test ) 2001-08-29 09:02:12 - Ctx( /examples ): XmlReader - init /examples webapps/examp les 2001-08-29 09:02:12 - Ctx( /examples ): Reading /opt/jakarta-tomcat-3.2.3/webapps /examples/WEB-INF/web.xml 2001-08-29 09:02:13 - Ctx( /examples ): Add user tomcat tomcat tomcat 2001-08-29 09:02:13 - Ctx( /examples ): Add user role1 tomcat role1 2001-08-29 09:02:13 - Ctx( /examples ): Add user both tomcat tomcat,role1 2001-08-29 09:02:13 - Ctx( /examples ): Loading -2147483646 jsp 2001-08-29 09:02:13 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2001-08-29 09:02:13 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 Below I?ll include the mod_jk.conf and worker.properties file. I checked all paths in these file and they all seem to be correct. Doing a telnet to port 8007 reports: [root@gerodt gero]# telnet localhost 8007 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is ?^]?. HANDLER THREAD PROBLEM: java.io.IOException: Stream broken java.io.IOException: Stream broken at org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp12ConnectionHa ndler.java:426) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12Connect ionHandler.java:147) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) So Tomcat is accepting requests on this port. A strange this I discovered is that the /var/log/httpd/mod_jk.log file remains empty when I do a: /etc/rc.d/rc5.d/S85httpd stop followed by a /etc/rc.d/rc5.d/S85httpd start However, when I do a: /etc/rc.d/rc5.d/S85httpd restart The mod_jk.log file contains: [jk_uri_worker_map.c (335)]: jk_uri_worker_map_t::uri_worker_map_close, NULL parameter [jk_uri_worker_map.c (185)]: In jk_uri_worker_map_t::uri_worker_map_free, NULL parameters
precompile JSP with jspc picking up changes in JSP source
I noticed that if I precompile JSP with jspc and setup servlet mapping in web.xml, changes to the original JSP file will not be picked up by Tomcat. Can I have both or are they mutually exclusive? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: precompile JSP with jspc picking up changes in JSP source
They are mutually exclusive. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 16, 2001 2:01 PM To: [EMAIL PROTECTED] Subject: precompile JSP with jspc picking up changes in JSP source I noticed that if I precompile JSP with jspc and setup servlet mapping in web.xml, changes to the original JSP file will not be picked up by Tomcat. Can I have both or are they mutually exclusive? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
