RE: [PATCH] For mod_jk.c (tomcat_3.2.2)

>Attached is a patch for mod_jk.c to more cleanly handle a bad >path for the workers.properties file. Currently, this is >handled in jk_init and if the call to map_read_properties >fails, then we just call jk_error_exit which in turn calls >exit(1). This causes some problems on NetWare becau

cvs commit: jakarta-tomcat/src/native/mod_jk/apache2.0 mod_jk.c

hgomez 01/04/04 22:27:53 Modified:src/native/mod_jk/apache1.3 mod_jk.c src/native/mod_jk/apache2.0 mod_jk.c Log: Clean handle of bad path to workers.properties file. Fix cleanup problem on Netware Submitted by: Mike Anderson Revision ChangesPath 1.8

Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]

Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. > An alternative view! > > On 4 Apr, Brad Cox wrote: >> At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: >>>I love the ar

RE: TC3.2.x and security problems

OK, I just tried this again (my results included inline) and in all cases I get a 404 error. I'm using Win2000 and JDK1.2.2. I'll try testing with JDK1.3 on Win2000 tomorrow and see if the problem follows the JDK version of the operating system. > -Original Message- > From: Stephan Sey

[PATCH] For mod_jk.c (tomcat_3.2.2)

Attached is a patch for mod_jk.c to more cleanly handle a bad path for the workers.properties file. Currently, this is handled in jk_init and if the call to map_read_properties fails, then we just call jk_error_exit which in turn calls exit(1). This causes some problems on NetWare because we

Better instructions for getting JSSE/JMX?

Hi, I've been trying for the last half-hour to get JSSE and JMX to build Tomcat 4.0. Could someone provide instructions for traversing the password-protected recursive mess that is the Sun site? I've progressed through these pages: http://java.sun.com/products/jsse/ http://jsecom9a.sun.com/ECo

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java

remm01/04/04 17:08:47 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: - Don't set an initial context factory. Revision ChangesPath 1.18 +4 -6 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java In

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

remm01/04/04 17:06:32 Modified:tester/src/tester/org/apache/tester Jndi01.java tester/web/WEB-INF web.xml Log: - Add test for bug 1202. Revision ChangesPath 1.2 +12 -1 jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Jndi01.java I

Re: "Just say no to JSP" Re: [Fwd: Tomcat may reveal script source code by URL trickery]

An alternative view! On 4 Apr, Brad Cox wrote: > At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: >>I love the article title: >>"Just say no to JSP" I am really sorry to see folks coming on this list, and also publishing to the general web articles deriding JSP and tomcat in particular. I have a

Re: "Just say no to JSP" Re: [Fwd: Tomcat may reveal scriptsource code by URL trickery]

At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: >I love the article title: >"Just say no to JSP" Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. >I'm so happy to see that more and more people are waking up to the fact that >JSP is bad. I'm also happy to see you worry about

Jasper34 refactoring proposal status

Hi folks, First, I want to apologize for how long it has taken me to get this proposal done. There have been external factors beyond my control, but requiring my time (more on that below). The good news, is that it is almost done. Also, the level of detail should lend itself to rapid implement

RE: TC3.2.x and security problems

>I can't reproduce that one, but could verify the following problems >on Linux: > >$ telnet localhost 8080 >Trying 127.0.0.1... >Connected to localhost. >Escape character is '^]'. >GET /examples/jsp/num/numguess.jsp >HTTP/1.0 200 OK >Content-Type: text/plain >Content-Length: 1237 >Last-Modified: T

Re: FW: Tomcat may reveal script source code by URL trickery 2

On Tue, Apr 03, 2001 at 04:04:46PM -0700, Jon Stevens wrote: > > -- > From: "Sverre H. Huseby" <[EMAIL PROTECTED]> > Reply-To: "Sverre H. Huseby" <[EMAIL PROTECTED]> > Date: Tue, 3 Apr 2001 10:25:26 +0200 > To: [EMAIL PROTECTED] > Subject: Tomcat may reveal script source code by URL trick

Re: TC3.2.x and security problems

On Wed, Apr 04, 2001 at 08:35:11AM -0500, Marc Saegesser wrote: > Has anyone on tomcat-dev been able to reproduce these problems using Tomcat > 3.2.x? I've been trying to reproduce the error using 3.2.1, 3.2.2b2 and > even 3.1.1. So far I always get a 404. I've never been able to get > director

[T4b3] mod_webapps

Folks, I am having a problem to make mod_webapp module for NT by follwing the instruction in server.xml with gcc. It's a kind of my wish that it will be nice to have either have an already-built module or VC++ makefile for WIN32. Is this too much to ask? Pae

"Just say no to JSP" Re: [Fwd: Tomcat may reveal script sourcecode by URL trickery]

on 4/4/01 11:06 AM, "Brad Cox" <[EMAIL PROTECTED]> wrote: > My article about a servlet-based alternative to JSP is in this > month's Dr. Dobbs Journal and at > http://www.ddj.com/articles/2001/0105/0105i/0105i.htm. The draft with > source code is at http://virtualschool.edu/wap. I love the artic

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets WebdavServlet.java

remm01/04/04 11:23:08 Modified:catalina/src/share/org/apache/catalina/servlets WebdavServlet.java Log: - Fix thread safety problems with the WebDAV servlet. The problem was that the JAXP document builder was not thread safe. Now, a new instance wi

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util Base64.java

remm01/04/04 11:12:19 Modified:catalina/src/share/org/apache/catalina/util Base64.java Log: - Update to the new version of the Xerces Base64 encoder/decoder. The old one had problems encoding binary content. Revision ChangesPath 1.2 +77 -49 jakarta-tomc

Re: [Fwd: Tomcat may reveal script source code by URL trickery]

My article about a servlet-based alternative to JSP is in this month's Dr. Dobbs Journal and at http://www.ddj.com/articles/2001/0105/0105i/0105i.htm. The draft with source code is at http://virtualschool.edu/wap. At 7:04 PM +0200 04/04/2001, Daniel Lopez wrote: >You're right! >That's another r

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade JspInterceptor.java

costin 01/04/04 10:49:55 Modified:src/facade22/org/apache/tomcat/facade JspInterceptor.java Log: Fix for Jsp compilation of declared jsps, thanks to William Barker. Submitted by: William Barker <[EMAIL PROTECTED]> Revision ChangesPath 1.19 +4 -1 jakarta-

Re: [Fwd: Tomcat may reveal script source code by URL trickery]

You're right! That's another reason to use a model 2 based approach but, of course, JSP still allows you to shoot you on your foot if you are fool enough to do so. That's one of the reasons we chose a model 2 based approach with XML-XSLT for the interface creation, no JSP involved: no feet in dang

RE: [Fwd: Tomcat may reveal script source code by URL trickery]

This is already fixed in 3.2.2. > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 04, 2001 11:09 AM > To: [EMAIL PROTECTED] > Subject: [Fwd: Tomcat may reveal script source code by URL trickery] > > > Reported against Tomcat 3.2.1 on Bug

Re: [Fwd: Tomcat may reveal script source code by URL trickery]

I know that these are just minor bugs in Tomcat (and other servlet containers as well), but man, this is getting ridiculous. This is clearly yet another reason to not use JSP. Especially when you have sites like this: Actually *encouragi

RE: [Fwd: Tomcat may reveal script source code by URL trickery]

TC 4.0B3 sources still missing in : http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0-b3/src/

[Fwd: Tomcat may reveal script source code by URL trickery]

Reported against Tomcat 3.2.1 on BugTraq. Craig Eric Daniel Mauricio wrote: > There is another way to get the source from a jsp page using Tomcat. > > If you don't write HTTP/1.0 or HTTP/1.1 in the end of the GET request, > you will get the source code and not the jsp processed. > > In other w

FW: Cocoon on iSeries = mod_jk is in use.

Just look what an AS/400 user send me. Thanks to Gal Shachor (ServletExpress & WebSphere). >-Original Message- >From: David Morris [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 04, 2001 5:12 PM >To: [EMAIL PROTECTED] >Subject: RE: Cocoon on iSeries > > >Henri, > >While investigating

Re: context factories

Btw, if I replace the instanceof test with a getClass().getName().equals("org.apache.naming.ResourceRef") it all works. -- - Torgeir

RE: servlet

A suggestion : First, you really need to manage a session for each user, because when a user get the file, he must release it when he has read it. That means that either he send another request to release the file or the session has "timeouted", which drives to the file release. Second, what you

TC3.2.x and security problems

Has anyone on tomcat-dev been able to reproduce these problems using Tomcat 3.2.x? I've been trying to reproduce the error using 3.2.1, 3.2.2b2 and even 3.1.1. So far I always get a 404. I've never been able to get directory listing or JSP source. The beta 2 time period is just about over. Wi

RE: problem

I'm not aware of any problems with . There was a bug in older versions where relative includes were relative to the top page rather than the current page. For example, page "a.jsp" includes "inc/b.jsp" and "b.jsp" includes "c.jsp". "c.jsp" should be located relative to "b.jsp". Older versions w

Re: context factories

"Craig R. McClanahan" wrote: > > If you don't mind specifying the resource factory class yourself, you > don't need to modify any code at all -- just configure it in server.xml > like this: > > > ... >type="com.mycompany.ContextPool"/> > > > factory

servlet

I am developing a web page, which will have the link to copyright protected reference materials. I will be using some web-builder tool such as front-page or dream-weaver. The problem faced is the implementation of access control over the refrence material, which is nothing but pdf files. the contr

problem

Are there any problems in using jakarta-tomcat-3.2.1 and the statement ? The statement, running well on older versions, doesn't work on jakarta-tomcat-3.2.1 with jdk 1.2.2. There is no according code segment within the JAVA-file generated by the JSP-engine. Regards, Dirk Keller

non-ascii characters in URL

hi, i have run into a problem with non ascii-url characters. When there is e.g. the German ä = ä in an URL, I have to encode it as follows: APACHE alone, non-ascii character anywhere: http://mydomain.de/d%E4mlich.html TOMCAT standalone, non-ascii character anywhere: http://mydomain.de:8080/req