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

remm01/04/05 19:45:48 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java WebdavServlet.java Log: - Add addiotional check to prevent using DELETE and PUT on URLs starting with /WEB-INF and /META-INF. Revision Changes

RE: TC3.2.x and security problems

I figured out the difference that's causing the URL to be decoded twice. It seems that as of JDK1.3.0 URLs using the file: scheme are now decoded like http: scheme URLs. For example file:c:\temp\%2e%2e\fubar.txt are interpreted as file:c:\temp\..\fubar.txt. In JDK1.2.2 this would have generated

Persistent connections in tomcat 3.x

Hi I wanted to findout if persistent/keepalive connections are supported by tomcat3.2 /3.3 In my application I am trying to invoke a servlet from a C application through plain sockets In my post header I am specifying Connection : keep-alive parameter, however when I try to reuse the connection a

Re: JNDI realm for Catalina

- Original Message - From: "Martin Smith" <[EMAIL PROTECTED]> > I wonder if it wouldn't be useful to permit a principal or a credential to be an > attribute in the user's (subject's) own entry, e.g., "creditbalance." (For some > types of data, I wonder if it may be more efficient to mai

Re: LoadBalancer worker

Great. I did the change you suggested and now it goes thru the loadbalancer worker. But now I have a question- It looks like this way all my ajp12 and ajp13 workers would be load balanced. So it might happen that the request may go to a ajp12/13 worker having low lb_value but that context might n

TC 4.0B2 problems when compiled with jikes : Was RE: TC 4.02 error => jikes 1.3 problem

Hi, Did someone (Remy, Craig) has an idea about the problem at startup with a TC 4.0 compiled with jikes 1.3 ? > >> Hi, >> >> Just trying a clean rebuilt of TC 4.0b2 and got : >> >> Using CLASSPATH: >> /var/tomcat4/bin/bootstrap.jar:/opt/IBMJava2-13/lib/tools.jar >> Using CATALINA_HOME: /v

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

On Thu, 5 Apr 2001, Jon Stevens wrote: > on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > So we need to fix it :-) After all that's one of the diferences between > > the zillion templating systems and jsp - a spec with a wide variety of > > implementations that improve. >

RE: LoadBalancer worker

did you do ? JkMount /examples/servlet/* loadbalancer JkMount /examples/*.jsp loadbalancer >-Original Message- >From: Vikas Bansal [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 05, 2001 9:31 PM >To: [EMAIL PROTECTED] >Subject: Re: LoadBalancer worker > > >Yes it is there. Sorry I did

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B4.txt

craigmcc01/04/05 12:37:01 Added: .RELEASE-NOTES-4.0-B4.txt Log: Start release notes for the next round. Revision ChangesPath 1.1 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B4.txt Index: RELEASE-NOTES-4.0-B4.txt

Re: LoadBalancer worker

Yes it is there. Sorry I did not mention it earlier- worker.list=myajp12_1, myajp12_2, myajp13_1, myajp13_2, loadbalancer GOMEZ Henri wrote: > >Hello, > >I want to enable the load balancer worker on Apache/Tomcat. Even though > >I have configured the workers.properties file as - > >worker.loadba

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

craigmcc01/04/05 12:30:40 Modified:catalina/src/conf web_23.dtd catalina/src/share/org/apache/catalina Context.java catalina/src/share/org/apache/catalina/core StandardContext.java catalina/src/share/org/apache/catalin

RE: LoadBalancer worker

>Hello, >I want to enable the load balancer worker on Apache/Tomcat. Even though >I have configured the workers.properties file as - >worker.loadbalancer.type=lb >worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, >myajp13_2 Don't forget to add loadbalancer to workers list ! >

LoadBalancer worker

Hello, I want to enable the load balancer worker on Apache/Tomcat. Even though I have configured the workers.properties file as - worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=myajp12_1, myajp13_1, myajp12_2, myajp13_2 The load balancer worker is not invoked, for I do see the

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

remm01/04/05 12:03:09 Modified:catalina/src/share/org/apache/catalina/servlets WebdavServlet.java Log: - Prevent COPY method from manipulating anything in /WEB-INF or /META-INF. Note : That could only happen when a user had red/write access on the

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

remm01/04/05 11:55:03 Modified:catalina/src/share/org/apache/catalina/servlets WebdavServlet.java Log: - Protect /WEB-INF and /META-INF from being deleted with a command like DELETE /webdav (which can easily be issued using the Slide WebDAV client

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

on 4/5/01 5:35 AM, "Matthew Dornquast" <[EMAIL PROTECTED]> wrote: > I could be wrong given I don't know the full context, but the code from the > article on this page: > http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead > safe, multiple requests coming in on different thre

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

remm01/04/05 11:47:52 Modified:catalina/src/share/org/apache/catalina/servlets DefaultServlet.java Log: - Path /. wasn't normalized properly (but /./ was). It's treated as a special case. Revision ChangesPath 1.34 +7 -4 jakarta-tomc

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

I could be wrong given I don't know the full context, but the code from the article on this page: http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead safe, multiple requests coming in on different threads at the same time would cause init() to be called multiple times. -Matt

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

--- Jon Stevens <[EMAIL PROTECTED]> wrote: > Mel, > > Please do not CC me directly as I'm already on the > list. Sorry - artifact of how I started the reply (from browsing the essay). Oops. > I have filed your > changes away for when I do my next revision of the > site (there are several > o

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

on 4/5/01 10:13 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > So we need to fix it :-) After all that's one of the diferences between > the zillion templating systems and jsp - a spec with a wide variety of > implementations that improve. > > I do agree with some of Jon's arguments - the

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

on 4/4/01 3:55 PM, "Brad Cox" <[EMAIL PROTECTED]> wrote: > Glad that change made it in. DDJ wanted "Just say no to HTML". Arggh. Yucky. >> 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 form validation issues. >>

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

Mel, Please do not CC me directly as I'm already on the list. I have filed your changes away for when I do my next revision of the site (there are several other people's comments that I want to integrate as well). I hear you and you made good suggestions. Also, I do have to say that those two ni

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

On Thu, 5 Apr 2001, Mel Martinez wrote: > The above paragraph describes a 'fundamental issue' > that has absolutely nothing to do with the Java Server > Pages specification and, rather, entirely to do with a > particular implementation of the specification. As And most of the other arguments ar

RE: mod_jk in a cluster

With the exception of failover (case 4 below), I believe that the first three cases can be handled by having your load balancer be "sticky" by client address to any of the app servers (machines running Apache with Tomcat). Thus if your load balancer receives a request from client some.client.net

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

--- Nick Bauman <[EMAIL PROTECTED]> wrote: > 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. > Without getting into the larger debate - actually agree with man

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

--- Nick Bauman <[EMAIL PROTECTED]> wrote: > 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. > Without getting into the larger debate - actually agree with man

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

on 4/5/01 5:01 AM, "Mark T. Harris" <[EMAIL PROTECTED]> wrote: > And of course, to debug JSP code, you really have to go after the generated > servlet. Well, read the whole essay...but here are a few good chapters relevant to the above:

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

on 4/5/01 3:45 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote: > I tried XSLT (... I really tried!!!) FreeMarker, WebMacro > and Velocity. > > I stay with Velocity. > (Life and templates sure can be simpler than XSLT.) > > Have fun, > Paulo Gaspar Now that is coming from the guy who prev

one file at a time.

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

RE: jasper bug

Hi, Thanks for the patch. But unfortunately, this would make jasper non-spec compliant. The JSP 1.1 spec in section 2.13.2.1 states that for the use of propertyName="*": If a parameter has a value of "", the corresponding property is not modified. No exception is mentioned for properties

[PATCH Suggestion] Tomcat 3.2.x adapter in load balancing using URL

Hi, The load balancer worker fail to handle load balancing if the application use sticky session managed by URL. The load balancer look for a the parameter "jsessionid" in the URL, and then can find the worker to contact for the request. First, the JK_PATH_SESSION_IDENTIFIER in jk_global.h is s

RE: TC3.2.x and security problems

Here's an update. I've installed JDK1.3.0 and JDK1.3.1-beta and tested the following URLs. All the tests were run on Win2000 using Tomcat 3.2.2b2. The only difference between these runs was the value of the JAVA_HOME environment variable. The security problems I could duplicate *only* occurred

jasper bug

org/apache/jasper/runtime/JspRuntimeLibrary.java in the method: introspecthelper This is a fix for the bug in handling jsp:setProperty for text fields (as posted in previous bug reports such as http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1207) where set method of property is not invoked for

LXR view of tomcat src?

Is there anyone that maintain an LXR (or cvsweb) view of the tomcat development source, or current beta3 source somewhere? -- - Torgeir

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

> I do have all the latest jar files from SUNW, and jakarta-apache. So I > don't know what the problems could be. My only complaints would be not > enough debug tools around to be able to single step through new code > when you are having problems, but I consider that minor at this point, > given

mod_jk in a cluster

Hi, we want to use tomcat 3.2.1 in a cluster-environment. This is not a request that someone else should code something. I think I have a solution, but may be others are interested in it too. We have, lets say three cluster-computer (server) and one simple load-balancer. The load-balancer doesn'

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

I sure had my "little" flames with Jon, but that is a very important thing I learned from him. I agree that the problem is there - not enough error info - and I had my share of such problems, but this is open source, so, you can fix it. OTOH, some developers can still learn a bit from this kin

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

I tried XSLT (... I really tried!!!) FreeMarker, WebMacro and Velocity. I stay with Velocity. (Life and templates sure can be simpler than XSLT.) Have fun, Paulo Gaspar > -Original Message- > From: Daniel Lopez [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 04, 2001 19:05

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

Hi Brad! Brad Cox wrote: > I should point out at the outset that this isn't to assign blame but > to point out a problem... namely, the complexity that developers must > deal with to get a working infrastructure in place. My application > uses Apache, JServ, Java, and the servlet engine from Tomc