RE: Port=0, binding in Random...
I proposed not to consider port 0 as a fatal error that will abort Tomcat but simply to ignore it and not to bind to any shutdown port at all. In our deployment we are not using the shutdown port, so having to have an unused 'shutdown' port open is just an invitation for problems (security wise). Thanks, Tal > -Original Message- > From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 23, 2001 4:56 PM > To: Tal Dayan; tomcat dev jakarta.apache.org > Subject: Port=0, binding in Random... > > > Anytime we construct a ServerSocket in Tomcat, we shouldn't allow > the value > "0" to be passed to the ServerSocket constructor, as that will > bind down to > a random port number... (and we don't want to open random ports on the > server, don't we?) > > For TC40, I believe the fix is pretty easy, in ServerSocketFactory... I > don't know if TC3x is affected... > > Thanks to Tal for noticing... > > Pier >
RE: Bug 1006, what's next ?
Yes, this is a typo. It should by 5. Here is a verbatim paste of the statement we are using: private static final int TIMEOUT = 5*60*1000; // read() timeout in ms ;-) Tal > -Original Message- > From: Shawn McMurdo [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 12:55 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Bug 1006, what's next ? > > > > Tal Dayan wrote: > > > [...] > > Yes, we tested the timeout patch all day yesterday with a > production system > > with real users and normal load and > > all the hanging threads and connections was cleaned up perfectly (we are > > using 'netstat' to > > get the number of HTTP connections and 'ps' to get the number > of thread and > > all is graphed around the clock by MRTG). We are running with a > relatively > > timeout of 5 minutes (50*60*1000) just to be on the safe side > but a shorter > > one can be used. > > Is 50 just a typo? Did you mean 5*60*1000? > Just thought I'd mention it in case it affects your testing. > Shawn > > -- > Shawn McMurdo mailto:[EMAIL PROTECTED] > Lutris Technologieshttp://www.lutris.com > Enhydra.Orghttp://www.enhydra.org > > >
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
Hi Henri,
Thanks for the fix.
The setSoTimeout controls the max time socketRead() blocks until it
timeouts. 15 seconds is way
too short IMHO. Especially if you don't provide a way to configure it.
If the user uploads a large file through a slow modem and the network has
soft problem for 15 secs, we don't
want to abort that connection yet.
Please consider to increase the hard coded value. Even several minutes
should be ok. I think 15 sec solves one problem
but creates a new one.
Also, are there other services that need to be modified (e.g. SSL) ?
Take care,
Tal
> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 3:28 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit:
> jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
>
>
> I suggest you to set the timeout in HttpConnectionHandler :
>
> // System.out.println("New Connection");
> try {
> // XXX - Add workarounds for the fact that the underlying
> // serverSocket.accept() call can now time out. This whole
> // architecture needs some serious review.
> if (connection == null)
> return;
> // System.out.print("1");
> socket=connection.getSocket();
> if (socket == null)
> return;
>
> socket.setSoTimeout(15000); // 15s Timeout - must be suffisant
> for http 1.0 request
>
> // System.out.print("2");
> InputStream in=socket.getInputStream();
> OutputStream out=socket.getOutputStream();
>
>
> Apache server use 300s (5mn) which is fine for HTTP 1.1 keep-alive
> connection. In http 1.0 connection 15s must be suffisant between accept()
> and read. The browser must'nt spend more than 15 seconds between to packet
> emission (even 1 byte packet) IMHO.
>
> We must forward the question to Apache gurus. I'll contact Ryan Bloom
> for more info
>
>
> >-Original Message-
> >From: GOMEZ Henri
> >Sent: Wednesday, March 21, 2001 12:19 AM
> >To: '[EMAIL PROTECTED]'
> >Subject: RE: cvs commit:
> >jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
> >
> >
> >You we're just too fast ;-)
> >
> >What happen to ajpx connector with that patch ?
> >
> >If ajp12 is a short life connection, ajp13 need permanent connection !
> >The setTimeOut in that case will broke it ;(
> >
> >Si la fortune vient en dormant, ça n'empêche pas les
> >emmerdements de venir au réveil.
> >-- Pierre Dac
> >
> >>-Original Message-
> >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >>Sent: Tuesday, March 20, 2001 11:21 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: cvs commit:
> >jakarta-tomcat/src/share/org/apache/tomcat/service
> >>PoolTcpEndpoint.java
> >>
> >>
> >>marcsaeg01/03/20 14:21:28
> >>
> >> Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
> >> PoolTcpEndpoint.java
> >> Log:
> >> Set the SO_TIMEOUT value on the accepted socket. This
> >prevents a DOS
> >> attacked by clients opening connections and never sending any data.
> >>
> >> The default timeout was also increased from 1 second to 5
> >>minutes (which
> >> is the default value used by Apache httpd).
> >>
> >> PR: 1006
> >> Submitted by: [EMAIL PROTECTED] (Tal Dayan)
> >>
> >> Revision ChangesPath
> >> No revision
> >>
> >>
> >> No revision
> >>
> >>
> >> 1.8.2.4 +9 -6
> >>jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTc
> >>pEndpoint.java
> >>
> >> Index: PoolTcpEndpoint.java
> >> ===
> >> RCS file:
> >>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
> >>tic/PoolTcpEndpoint.java,v
> >> retrieving revision 1.8.2.3
> >> retrieving revision 1.8.2.4
> >> diff -u -r1.8.2.3 -r1.8.2.4
> >> --- PoolTcpEndpoint.java 2000/11/17 23:19:55 1.8.2.3
> >> +++ PoolTcpEndpoint.java 2001/03/20 22:21:25 1.8.2.4
> >> @@ -1,7 +1,7 @@
> >> /*
> >> - * $Header:
> >>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
> >>tic/PoolTcpEndpoint.java,v 1.8.2.3 2000/11/17 23:19:55 craigmcc Exp $
Control Channel and Thread Pool (was bug 1006)
#x27;t want to take advantage of overhead-free > thread data ) > > None of those would resolve the DOS problem, but I think it would be nice > to have them (and very easy to implement - without affecting the current > functionality ) Yes, it is hard to have a DOS safe solution (e.g. how do you handle excessive creation of sessions). The first priority IMHO should be to make the thing work well in normal conditions without introducing new vulnerabilities. > > > Costin > Tal > > > > > On Tue, 20 Mar 2001, Tal Dayan wrote: > > > Hi, > > > > Our first priority is to make Tomcat to work in normal > conditions with good > > intentioned users. We will > > worry later about DOS (as long as we don't introduce new > vulnerabilities). > > > > Yes, we tested the timeout patch all day yesterday with a > production system > > with real users and normal load and > > all the hanging threads and connections was cleaned up perfectly (we are > > using 'netstat' to > > get the number of HTTP connections and 'ps' to get the number > of thread and > > all is graphed around the clock by MRTG). We are running with a > relatively > > timeout of 5 minutes (50*60*1000) just to be on the safe side > but a shorter > > one can be used. > > > > Note that I am in no way and expert in Tomcat nor do I claim to > understand > > all the implications of the patch so we need some qualified person to > > understand the implication and make sure it does not break anything. For > > example, if another service like Ajp uses this connection pool > for long term > > connections that need to wait long periods for a data from some > client (e.g. > > a front end web server, client side applets, etc), the patch > will break it. > > The patch assumes that the connections are should never be idle > for a long > > period of time. > > > > As for Apache, it supports a request timeout (see > > http://httpd.apache.org/docs/mod/core.html#timeout) and this will > > will eventually cleanup hanging connections. The timeout in this case is > > longer because it is for the entire request and the cleanup > will be slower. > > > > Implementing a similar query timeout in Tomcat may require things like > > asynchronous thread kill (yuck) or some synchronous termination of the > > worker threads, for example by closing the sockets they are > waiting on (I > > think this will release the socketRead() but I am not sure). > But this is of > > course a more involved change than simply adding the timeout statement. > > Having an asynchronous I/O may help here (see Bug Parade > > http://developer.java.sun.com/developer/bugParade/bugs/4075058.html). > > > > BTW, does Tomcat 4.X has the same problem ? > > > > Tal > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, March 20, 2001 7:03 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Bug 1006, what's next ? > > > > > > > > > Hi, > > > > > > I had a (long) weekend without computers. But I still found > one and read > > > the mail once - and your report is very serious and important > ( and not > > > easy to fix ). You have (at least ) my full attention. The read > > > timeout will be checked in soon - but the general problem > with a servlet > > > hanging a thread ) is very hard to resolve (or I don't know any good > > > solution ). > > > > > > We could stop setting an upper limit on the thread count ( we > still have > > > the OS upper limit ), and we could also use the (dangerous, > > > deprecated) suspend/terminate on the thread that is taking > too much time. > > > > > > Have you tried any fix ? The timeout will not resolve the > "bursts" ( and > > > high-loaded servers ) - unless it is very short. > > > > > > BTW, this is not a tomcat-specific problem ( I would guess Apache does > > > have the same issue - and we need to find how they deal with that ). > > > > > > Costin > > > > > > > > > On Tue, 20 Mar 2001, Tal Dayan wrote: > > > > > > > > > > > Two days ago I filed a bug report regarding a sever hanging > problem in > > > > PollTcpEndpoint of Tomcat 3.x. The bug is > > > > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and > > > also include a > > > > suggestion for a patch. > > > > > > > > Since then I did not notice any change in the status or > > > resolution of the > > > > bug report nor any > > > > indication that it got anywhere. > > > > > > > > 1. Is this is the right place to file the bug ? > > > > > > > > 2. Is the bug filed correctly ? > > > > > > > > 3. Should I do anything else to make sure the bug gets the > > > attention of the > > > > relevant maintainers ? > > > > > > > > Thanks, > > > > > > > > Tal > > > > > > > > > > > > > > > > > > >
RE: Bug 1006, what's next ?
Hi Mark, Yes, we will be glad to test it. BTW, we changed the code of the patch slightly. The timeout is now set even if there is no factory. I am not sure where these factories are coming from and whether it can be null but it seems to be safer this way. The change is documented in the bug report at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 Tal > -Original Message- > From: Marc Saegesser [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 6:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Bug 1006, what's next ? > > > Tal, > > It has my attention. I'm in the process of finalizing the second beta > release of Tomcat 3.2.2 and I will try to include this patch. > Would you be > able to test Tomcat 3.2.2 beta 2 (when its ready) to verify that this is > working correctly? > > Marc Saegesser > > > -Original Message- > > From: Tal Dayan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, March 20, 2001 2:27 AM > > To: [EMAIL PROTECTED] > > Subject: Bug 1006, what's next ? > > > > > > > > Two days ago I filed a bug report regarding a sever hanging problem in > > PollTcpEndpoint of Tomcat 3.x. The bug is > > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and > > also include a > > suggestion for a patch. > > > > Since then I did not notice any change in the status or > resolution of the > > bug report nor any > > indication that it got anywhere. > > > > 1. Is this is the right place to file the bug ? > > > > 2. Is the bug filed correctly ? > > > > 3. Should I do anything else to make sure the bug gets the > > attention of the > > relevant maintainers ? > > > > Thanks, > > > > Tal > > > > > >
RE: Bug 1006, what's next ?
Hi, Our first priority is to make Tomcat to work in normal conditions with good intentioned users. We will worry later about DOS (as long as we don't introduce new vulnerabilities). Yes, we tested the timeout patch all day yesterday with a production system with real users and normal load and all the hanging threads and connections was cleaned up perfectly (we are using 'netstat' to get the number of HTTP connections and 'ps' to get the number of thread and all is graphed around the clock by MRTG). We are running with a relatively timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter one can be used. Note that I am in no way and expert in Tomcat nor do I claim to understand all the implications of the patch so we need some qualified person to understand the implication and make sure it does not break anything. For example, if another service like Ajp uses this connection pool for long term connections that need to wait long periods for a data from some client (e.g. a front end web server, client side applets, etc), the patch will break it. The patch assumes that the connections are should never be idle for a long period of time. As for Apache, it supports a request timeout (see http://httpd.apache.org/docs/mod/core.html#timeout) and this will will eventually cleanup hanging connections. The timeout in this case is longer because it is for the entire request and the cleanup will be slower. Implementing a similar query timeout in Tomcat may require things like asynchronous thread kill (yuck) or some synchronous termination of the worker threads, for example by closing the sockets they are waiting on (I think this will release the socketRead() but I am not sure). But this is of course a more involved change than simply adding the timeout statement. Having an asynchronous I/O may help here (see Bug Parade http://developer.java.sun.com/developer/bugParade/bugs/4075058.html). BTW, does Tomcat 4.X has the same problem ? Tal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 7:03 AM > To: [EMAIL PROTECTED] > Subject: Re: Bug 1006, what's next ? > > > Hi, > > I had a (long) weekend without computers. But I still found one and read > the mail once - and your report is very serious and important ( and not > easy to fix ). You have (at least ) my full attention. The read > timeout will be checked in soon - but the general problem ( with a servlet > hanging a thread ) is very hard to resolve (or I don't know any good > solution ). > > We could stop setting an upper limit on the thread count ( we still have > the OS upper limit ), and we could also use the (dangerous, > deprecated) suspend/terminate on the thread that is taking too much time. > > Have you tried any fix ? The timeout will not resolve the "bursts" ( and > high-loaded servers ) - unless it is very short. > > BTW, this is not a tomcat-specific problem ( I would guess Apache does > have the same issue - and we need to find how they deal with that ). > > Costin > > > On Tue, 20 Mar 2001, Tal Dayan wrote: > > > > > Two days ago I filed a bug report regarding a sever hanging problem in > > PollTcpEndpoint of Tomcat 3.x. The bug is > > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and > also include a > > suggestion for a patch. > > > > Since then I did not notice any change in the status or > resolution of the > > bug report nor any > > indication that it got anywhere. > > > > 1. Is this is the right place to file the bug ? > > > > 2. Is the bug filed correctly ? > > > > 3. Should I do anything else to make sure the bug gets the > attention of the > > relevant maintainers ? > > > > Thanks, > > > > Tal > > > > > >
Bug 1006, what's next ?
Two days ago I filed a bug report regarding a sever hanging problem in PollTcpEndpoint of Tomcat 3.x. The bug is at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a suggestion for a patch. Since then I did not notice any change in the status or resolution of the bug report nor any indication that it got anywhere. 1. Is this is the right place to file the bug ? 2. Is the bug filed correctly ? 3. Should I do anything else to make sure the bug gets the attention of the relevant maintainers ? Thanks, Tal
RE: Missing timeout in PoolTcpEndpoint ?
I just submitted a bug for it that describes how to reproduce it: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 Tal
Missing timeout in PoolTcpEndpoint ?
Hello, Our production system (Tomcat 3.2.1, IBM 1.3 build cx130-20001124, Redhat 6.2) suffers from a sever problem of hanging threads and we are trying to come with a quick fix for it. When Tomcat runs (Standalone mode) it accumulate threads that hangs forever. Later, when the number of hanging threads reaches the max number of threads, it does not response anymore. A typical stack of an hanging threads looks like "Thread-62" (TID:0x402e5cc0, sys_thread_t:0x86a9078, state:S, native ID:0x1e446) prio=5 at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:104) at java.io.BufferedInputStream.fill(BufferedInputStream.java:192) at java.io.BufferedInputStream.read(BufferedInputStream.java:210) at org.apache.tomcat.service.http.HttpRequestAdapter.doRead(HttpRequestAdapter. java:115) at org.apache.tomcat.core.BufferedServletInputStream.doRead(BufferedServletInpu tStream.java:106) at org.apache.tomcat.core.BufferedServletInputStream.read(BufferedServletInputS tream.java:128) at javax.servlet.ServletInputStream.readLine(ServletInputStream.java:138) at org.apache.tomcat.service.http.HttpRequestAdapter.readNextRequest(HttpReques tAdapter.java:129) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:195) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:498) Also, when we do 'netstat -an' we see permanent HTTP connection of about the same number of the stuck threads, and a 'tcpdump' shows for hours no activity from the clients at the other side of the 'connection'. An examination of the source codes shows that PoolTcpEndpoint has a private member for timeout but it is not used. A similar member in SimpleTcpEndpoint is used in a call Socket.setSoTimeout(). Since setSoTimeout() controls the timeout of a single read() operation, setting it few minutes will guarantee that the hanging threads will eventually get released. Any idea address this problem will be greatly appreciated. Was this problem fixed in a newer version of Tomcat (which is table enough for production)? Should we apply the patch ourselves ? Should we file a bug for it ? This is a major problem for us and our production system hardly survives a single day, so your help will be greatly appreciated. Thanks, Tal
RE: Any plan to support status 304 ?
Sounds great.
Will 4.0 beta 2.0 be production worthy ?
Tal
> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 16, 2001 8:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Any plan to support status 304 ?
>
>
> > The Tomcat 3.2 standalone does not seem to support http status code 304
> > ('if-modified-since', code SC_NOT_MODIFIED) and is always
> sending back the
> > entire file, even it has not been modified.
> >
> > Is it going to be supported by versions '3.3' or 4.0 ?
>
> All HTTP/1.1 ifs headers should be supported in 4.0, as well as ranged
> requests (for resuming), and many other things.
> If you're using TC in standalone mode, I would recommend upgrading to 4.0
> beta 2 when it's released.
>
> Remy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Any plan to support status 304 ?
The Tomcat 3.2 standalone does not seem to support http status code 304
('if-modified-since', code SC_NOT_MODIFIED) and is always sending back the
entire file, even it has not been modified.
Is it going to be supported by versions '3.3' or 4.0 ?
Should I file a request for it in the bug system ?
Thanks,
Tal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Proposed name encoding patch
Yes, this may work. Just remember to encode the escape char '_' as well even though it is a valid java id char. Otherwise, the mapping may not be unique. Tal > -Original Message- > From: Steve Downey [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 18, 2001 10:50 AM > To: '[EMAIL PROTECTED]' > Subject: RE: Proposed name encoding patch > > > I was looking at this last night, by coincidence. It seems to me that the > class > name is encoding too much information. It's duplicating the > package as part > of > the class name. I suspect it's getting confused between '/', '\', > File.separatorChar, etc. > > It's also encoding characters that are legal in java class names > that do not > happen to be > Character.isLetterOrDigit(). Should probably be > Character.isJavaIdentifierStart and > Character.isJavaIdentifierPart > > > -Original Message- > From: Tal Dayan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 16, 2001 3:41 AM > To: [EMAIL PROTECTED] > Subject: Proposed name encoding patch > > > Hello, > > This is my first posting to this list so please bare with me. > > We are having problems with the jsp name mangling (bug 330 at > http://znutar.cortexity.com/BugRatViewer/ShowReport/330). > > Every '/' or '_' char in the jsp path is converted to 6 chars which easily > extend the file path beyond Win NT limitation of 256 chars. As a > result, the > JSP compilation fails with the following error: > > org.apache.jasper.JasperException: Unable to compile class for JSPerror: > Can't write: > > D:\tomcat\appserv\work\localhost_8080\system\admin\modes\start\acc > ount\_0002 > fsystem_0002fadmin_0002fmodes_0002fstart_0002faccount_0002fpage_00 > 05fadmin_0 > 005fstart_0005faccount_0005fpassword_0002ejsppage_0005fadmin_0005f > start_0005 > faccount_0005fpassword_jsp_0.class > > A quick look at the code reveals that the mangling is done by the method > CommandLineCompiler.mangleChar() so we plan to modify the method > to generate > a more compact encoding, especially for common chars such as '/', '_', and > '.'. > > What is the view of the list regarding the proposed modification and how > should we proceed to maximize the changes that our patch will be > included in > the official Tomcat code ? > > Thanks, > > Tal > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > <><><><><><><><><><><><><><><><><><><><><>This electronic mail > transmission > may contain confidential information and is intended only for the > person(s) > named. Any use, copying or disclosure by any other person is strictly > prohibited. If you have received this transmission in error, > please notify > the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Patch for bug 330
Yes Steve, you are right, this is not a complete solution, but it is simple,
and will reduce the pain at least for a while. In the example that you gave,
the new encoding will save about 50 chars (four for each '/') so you can add
6 or 7 Very's to the path. This is a low risk patch can be squeezed to the
next maintenance release of 3.X.X.
A more general solution will require getting deeper into the code. For
example, the server could save the jsp classes in a directory tree that
matches the jsp path. This way, the limit will not be on the overall path
length but only the length of a single item in the path.
Tal
> -Original Message-
> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 12:33 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Patch for bug 330
>
>
> I suspect that this won't fix the underlying problem. The class name
> includes the path and makes it too easy to overflow the filename
> limit. For
> example:
>
> /jsp/snp/a/very/very/very/very/very/very/deeply/nested/snoop.jsp
>
> will not compile, while
>
> /jsp/snp/a/very/very/very/very/very/deeply/nested/snoop.jsp
>
> (with one less very) will.
>
> The one that works gets translated in the current scheme (On NT 2000, jdk
> 1.3, Tomcat standalone) to
> _0002fjsp_0002fsnp_0002fa_0002fvery_0002fvery_0002fvery_0002fvery_
> 0002fvery_
> 0002fdeeply_0002fnested_0002fsnoop_0002ejspsnoop.class
> in the tomcat\work\localhost_8080%2Fexamples directory.
>
> Compacting the mangling will allow a few more 'verys' to be
> translated, but
> it is still broken.
>
>
>
> -Original Message-
> From: Tal Dayan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 18, 2001 3:06 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Patch for bug 330
>
>
> Hi Costin,
>
> Here is our patch for bug 330, Priority: high, Severity
> serious.(http://znutar.cortexity.com/BugRatViewer/ShowReport/330).
>
> Having this patch included the official release of 3.X.X will make Tomcat
> usable for us since we could not port our application from WebSphere to
> Tomcat 3.2.1 because of this problem.
>
> To apply the patch, all you need to do is to replace the method
> mangleChar()
> in JspCompiler.java with the new code that is included at the end of this
> message.
>
> BTW, the file CommandLineCompiler also has a similar mangleChar()
> method. I
> am not sure when this is used but you may want to consolidate the two.
>
> The new encoding has two forms, a short one and a general one.
> The short one
> is used for few common chars such as '_' and '/' and '/'. This
> encoding maps
> into a two char string of the form '_' where is a non hex
> char (g-z)
> (e.g. '_' --> '__', '.' --> '_p' etc). It is a more compact, 'readable'
> (e.g. the 'p' in '.'-->'_p' stands for 'period') and is more
> efficient since
> it does not create any object.
>
> The general form is used for the rest of the chars, including
> Unicode's. It
> is of variable length and for most of the common chars (e.g.
> ASCII) it will
> result in a shorter encoding than the one currently used. This
> encoding uses
> the form '_' 'x' where is a variable length hex
> representation of the numeric value of the char (e.g. "_f4x", "_123ax").
>
> Please review the patch and 'squeeze' it to the next maintenance
> release of
> 3.X.X.
>
> Thanks,
>
> Tal
>
>
>
> new code --
>
> /*
> * Encode special chars using a representation that contains only
> * simple chars that can be used in class names (digits, letters,
> * and '_').
> */
> private static final String mangleChar(char ch) {
>
> if(ch == File.separatorChar) {
> ch = '/';
> }
>
> /*
> * Use a compact and more readable encoding for few common chars.
> *
> * Note: the char we append after the '_' should not be hex digit
> * to avoid ambiguity with the general encoding we perform for the
> rest of
> * the chars.
> */
> if (ch == '_')
> {
> return "__"; // underscore
> }
>
> if (ch == '-')
> {
> return "_m"; // minus
> }
>
> if (ch == '.')
> {
> return "_p"; // period
> }
>
> if (ch == '/'
Patch for bug 330
Hi Costin,
Here is our patch for bug 330, Priority: high, Severity
serious.(http://znutar.cortexity.com/BugRatViewer/ShowReport/330).
Having this patch included the official release of 3.X.X will make Tomcat
usable for us since we could not port our application from WebSphere to
Tomcat 3.2.1 because of this problem.
To apply the patch, all you need to do is to replace the method mangleChar()
in JspCompiler.java with the new code that is included at the end of this
message.
BTW, the file CommandLineCompiler also has a similar mangleChar() method. I
am not sure when this is used but you may want to consolidate the two.
The new encoding has two forms, a short one and a general one. The short one
is used for few common chars such as '_' and '/' and '/'. This encoding maps
into a two char string of the form '_' where is a non hex char (g-z)
(e.g. '_' --> '__', '.' --> '_p' etc). It is a more compact, 'readable'
(e.g. the 'p' in '.'-->'_p' stands for 'period') and is more efficient since
it does not create any object.
The general form is used for the rest of the chars, including Unicode's. It
is of variable length and for most of the common chars (e.g. ASCII) it will
result in a shorter encoding than the one currently used. This encoding uses
the form '_' 'x' where is a variable length hex
representation of the numeric value of the char (e.g. "_f4x", "_123ax").
Please review the patch and 'squeeze' it to the next maintenance release of
3.X.X.
Thanks,
Tal
new code --
/*
* Encode special chars using a representation that contains only
* simple chars that can be used in class names (digits, letters,
* and '_').
*/
private static final String mangleChar(char ch) {
if(ch == File.separatorChar) {
ch = '/';
}
/*
* Use a compact and more readable encoding for few common chars.
*
* Note: the char we append after the '_' should not be hex digit
* to avoid ambiguity with the general encoding we perform for the
rest of
* the chars.
*/
if (ch == '_')
{
return "__"; // underscore
}
if (ch == '-')
{
return "_m"; // minus
}
if (ch == '.')
{
return "_p"; // period
}
if (ch == '/')
{
return "_s"; // seperator
}
/*
* Encode the general case. We encode the char as follows
*
* '_' 'x'
*
* Where h is is a variable length Hexadecimal
* represnetation of the numeric value
* of the char as returned by IntegertoHexString().
*/
return "_" + Integer.toHexString(ch) + "x";
}
old code
private static final String mangleChar(char ch) {
if(ch == File.separatorChar) {
ch = '/';
}
String s = Integer.toHexString(ch);
int nzeros = 5 - s.length();
char[] result = new char[6];
result[0] = '_';
for (int i = 1; i <= nzeros; i++)
result[i] = '0';
for (int i = nzeros+1, j = 0; i < 6; i++, j++)
result[i] = s.charAt(j);
return new String(result);
}
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 16, 2001 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposed name encoding patch
>
>
> It's worth to mention that both JSP encoding and work dir encoding are
> resolved/improved in 3.3 - and the code can be easily ported back /
> reused.
>
> I'll take a look at both patches and try to integrate them into 3.3 also (
> what is not covered already )
>
> --
> Costin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: denial of service attack
You proposal is based on determination that the request is 'from the same
client'. What is your definition for a 'client' and how do you determine if
two requests are form the same client ?
Tal
> -Original Message-
> From: Scott Christley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 17, 2001 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: denial of service attack
>
>
>
> I must apologize first by saying that I originally found this bug with
> Jserv not Tomcat, but those of you who are familiar with Tomcat
> internals can probably tell fairly quickly if this would still be an
> issue.
>
> =
> This bug deals with an out of memory condition within Jserv which is
> more a design/security issue. The scenario is that when a session is
> created by a servlet; memory is allocated by the JVM for that session
> and stays allocated until these two conditions occur 1) the servlet
> invalidates the session or the session timeout is reached which
> invalidates the session and 2) JVM garbage collection returns that
> allocated memory back to the heap.
>
> The reason this is a design/security issue is because any normal Java
> Servlet application can be used for a denial of service attack. The
> Java Servlet specification encourages applications to use sessions if
> they wish to maintain state. A hacker can easily discover if any
> application is a Java Servlet which uses sessions by checking to see if
> the JSESSIONID cookie is defined; if the hacker finds one then a simple
> program can be used to increase the memory usage on the server and crash
> the JVM.
>
> while (server is still up)
>send an HTTP request to the servlet URL which creates the session
>
> The timeout variable and the maximum java heap size are the only two
> ways that the application can attempt to avoid this attack; by setting a
> short timeout and a large heap size, one can hope that there is a
> sufficient span to handle all of the requests (i.e. the timeout kicks in
> before the memory has max'ed out). But there are problems with this:
>
> * Set a timeout too short and normal users get their session invalidated
> before they are able to complete normal usage of the application.
> * Java heap size reserves memory which cannot be swapped out (on solaris
> at least), so a large heap size puts a strain on the server's memory.
> * The hacker can always deploy additional clients to generate more
> concurrent requests.
> =
>
> I have been writing stress tests for Jserv, Tomcat, and our own servlet
> engine; when I brought this issue up with the developers here, I
> essentially got my hand slapped (*sigh*) and told "application
> developers must deal with this, it is not the servlet engines
> responsibility". Which I think is a highly unfortunate answer because
> HttpSession is a core servlet API and telling developers that they
> cannot use it and should use an alternate mechansim, just seems wrong to
> me. So, I figured I would post a message to this list for discussion.
>
> I did have an idea for how this issue can be resolved; I've not totally
> thought it through, but it may be a good start.
>
> =
> Given a parameter (num_of_sessions) which is the maximum number of new
> sessions.
> Given a parameter (time_period) which is a time interval.
>
> Implement a verification such that maximum number of new sessions that
> can be created from the same client within a time interval. This would
> require that you maintain a creation date and client identifier with
> each session.
>
> if (creating a new session)
> {
>session_count = 0
>Loop through set of sessions for that client
>{
> /* Was this session created within the time period */
> if ((current_date - creation_date_of_session) > time_period)
> ++session_count;
>}
>if ((session_count + 1) > num_of_sessions)
> /* Good possibility we are being attacked */
>else
> /* create the new session */
> }
> =
>
> Presumably default values could be given to the num_of_session and
> time_period parameters which still allow the problem user (somebody
> opening up multiple browser windows, stoppng/starting browser, etc) to
> gain access to the application, yet small enough to prevent the JVM from
> consuming large amounts of memory before the attack is discovered. Once
> an attack is discovered, the servlet engine could be proactive and
> delete all of the sessions created by the client to free up the memory,
> log messages, etc.
>
> cheers
> Scott
>
> /* Thankfully Oracle doesn't speak for me, nor vice-versa */
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Proposed name encoding patch
Hi Kim, That's great. I have few questions: 1. Have you submitted the patch to the Tomcat repository ? If so, do you know in what version it will be released ? 2. Also, the encoding that you use is of the form %hh where 'hh' is an hex value. I had the implression that for public classes, the .class file name should match the file name. Don't you have a problem with that (since a class name cannot contain '%') ? 3. In what part of the code did you made the change, was it in mangleChar() method ? Thanks Tal > -Original Message- > From: Pilho Kim [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 16, 2001 11:06 AM > To: [EMAIL PROTECTED] > Subject: Re: Proposed name encoding patch > > > Hi, Tal > > I have ever solved the problem already. > Try to check > http://w4.metronet.com/~wjm/tomcat/2000/Aug/msg00595.html > > Thanks, > Kim > > > On Tue, 16 Jan 2001, Tal Dayan wrote: > > > Hello, > > > > This is my first posting to this list so please bare with me. > > > > We are having problems with the jsp name mangling (bug 330 at > > http://znutar.cortexity.com/BugRatViewer/ShowReport/330). > > > > Every '/' or '_' char in the jsp path is converted to 6 chars > which easily > > extend the file path beyond Win NT limitation of 256 chars. As > a result, the > > JSP compilation fails with the following error: > > > > org.apache.jasper.JasperException: Unable to compile class for JSPerror: > > Can't write: > > > > > D:\tomcat\appserv\work\localhost_8080\system\admin\modes\start\acc > ount\_0002 > > > fsystem_0002fadmin_0002fmodes_0002fstart_0002faccount_0002fpage_00 > 05fadmin_0 > > > 005fstart_0005faccount_0005fpassword_0002ejsppage_0005fadmin_0005f > start_0005 > > faccount_0005fpassword_jsp_0.class > > > > A quick look at the code reveals that the mangling is done by the method > > CommandLineCompiler.mangleChar() so we plan to modify the > method to generate > > a more compact encoding, especially for common chars such as > '/', '_', and > > '.'. > > > > What is the view of the list regarding the proposed modification and how > > should we proceed to maximize the changes that our patch will > be included in > > the official Tomcat code ? > > > > Thanks, > > > > Tal > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Proposed name encoding patch
Hi Costin, I looked at the code at (one long line) http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat/src/share/org/apac he/jasper/compiler/CommandLineCompiler.java?rev=1.6&content-type=text/vnd.vi ewcvs-markup The mangleChar() method seems to have the old code that encodes as _x where x is an hex digit. If I understand the code correctly, this is where we need to make the patch. If this is solved somewhere else, please send me pointer so I can give it a try. In case we need to write a new encoding method, here are some possible requirements, I am not sure which of them are relevant and which are not. 1. The encoding of any path should be unique. 2. The file name without the '.class' extension) should be a valid Java class name. 3. The encoding should be intuitive. 4. The encoding should be compact, at least for common chars. 5. The encoding should support JSP name with Unicode chars. 6. Runtime efficiency. The current encoding for example creates 3 object for each mangled char. Any comment from members of the list will be greatly appreciated. Tal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 16, 2001 11:40 AM > To: [EMAIL PROTECTED] > Subject: Re: Proposed name encoding patch > > > It's worth to mention that both JSP encoding and work dir encoding are > resolved/improved in 3.3 - and the code can be easily ported back / > reused. > > I'll take a look at both patches and try to integrate them into 3.3 also ( > what is not covered already ) > > -- > Costin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Proposed name encoding patch
Hello, This is my first posting to this list so please bare with me. We are having problems with the jsp name mangling (bug 330 at http://znutar.cortexity.com/BugRatViewer/ShowReport/330). Every '/' or '_' char in the jsp path is converted to 6 chars which easily extend the file path beyond Win NT limitation of 256 chars. As a result, the JSP compilation fails with the following error: org.apache.jasper.JasperException: Unable to compile class for JSPerror: Can't write: D:\tomcat\appserv\work\localhost_8080\system\admin\modes\start\account\_0002 fsystem_0002fadmin_0002fmodes_0002fstart_0002faccount_0002fpage_0005fadmin_0 005fstart_0005faccount_0005fpassword_0002ejsppage_0005fadmin_0005fstart_0005 faccount_0005fpassword_jsp_0.class A quick look at the code reveals that the mangling is done by the method CommandLineCompiler.mangleChar() so we plan to modify the method to generate a more compact encoding, especially for common chars such as '/', '_', and '.'. What is the view of the list regarding the proposed modification and how should we proceed to maximize the changes that our patch will be included in the official Tomcat code ? Thanks, Tal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
