RE: [j-t-c] Thread problem in jk_uri_worker_map.c
Thanks. I think I already do have karma for j-t-c. I've been away from the Jakarta projects for a long time, however, and I haven't been able to keep up with what all the details of what's going on. I didn't feel comfortable coming back out of nowhere and checking in code right away since I know that you are trying to get a release out. -- Marc -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 10:16 PM To: [EMAIL PROTECTED] Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c I'll put this one in in the interest of time, but Marc should be given karma (like any other Tomcat committer) to j-t-c, if he doesn't have it already. Marc Saegesser [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] G, the attachment got stripped from my last message. Here's the diff inline: Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 diff -u -r1.12 jk_connect.c --- jk_connect.c 29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c 29 Aug 2003 21:37:12 - @@ -101,6 +101,9 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif /** resolve the host IP */ int jk_resolve(char *host, -- Marc -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:41 PM To: Tomcat Developers List Subject: RE: [j-t-c] Thread problem in jk_uri_worker_map.c The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - 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: [j-t-c] Thread problem in jk_uri_worker_map.c
The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - 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: [j-t-c] Thread problem in jk_uri_worker_map.c
G, the attachment got stripped from my last message. Here's the diff inline: Index: jk_connect.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v retrieving revision 1.12 diff -u -r1.12 jk_connect.c --- jk_connect.c29 Aug 2003 13:07:52 - 1.12 +++ jk_connect.c29 Aug 2003 21:37:12 - @@ -101,6 +101,9 @@ #include apr_general.h #endif +#if defined(WIN32) +typedef u_long in_addr_t; +#endif /** resolve the host IP */ int jk_resolve(char *host, -- Marc -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 4:41 PM To: Tomcat Developers List Subject: RE: [j-t-c] Thread problem in jk_uri_worker_map.c The file common/jk_connect.c no longer compiles on Win32 because the in_addr_t type is not defined on that platform. The attached patch fixes the build problem, but there is probably a better way. -- Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2003 8:55 AM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c Henri Gomez wrote: Marc Saegesser a écrit : That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc A good reason to have delayed jk 1.2.5 ;) Ok, I have seen Henri's commit for the in_addr build fix. And I have seen Bill's patches for the uri mapping thread safe bug. If I don't hear about any more open items/bugs for mod_jk 1.2.5 in the next few days I will generate another test release distribution over the weekend. Regards, Glenn - 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: [j-t-c] Thread problem in jk_uri_worker_map.c
That makes sense. The manipulations that map_uri_to_worker() does always make the string shorter so there is no need to worry about the modifiable string passed in being too short and needing reallocated. Trying to fix this in the jk/common code is, I think, a waste of effort. -- Marc -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 7:16 PM To: Tomcat Developers List Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c The easiest solution would be to change the map_uri_to_worker contract to be that the uri parameter is modifiable. Then Apache can dup it using the request's pool, it looks like IIS is doing this most of the time anyway, and Netscape isn't using map_uri_to_worker at all. That leave Domino, which I don't really know. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 3:11 PM Subject: [j-t-c] Thread problem in jk_uri_worker_map.c I've run into a threading problem in /j-t-c/native/jk/common/jk_uri_worker_map.c. The problem has been around for a long time, but I believe the changes checked in for version 1.15 on June, 27, 2003 made the problem worse. I have only been able to reproduce the problem on multi-processor machines running under a fairly heavy load. Unfortunately, I don't have a good solution, yet. The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in the map_uri_to_worker() function. The temp pool is used to store a copy of the incoming URI so that it can be altered to remove any jsessionid and to remove multiple adjacent / characters. The problem is that this single pool is shared by all the worker threads so if multiple threads are executing map_uri_to_worker() simultaneously there is a chance that the pool will get corrupted. This can happen in two ways. The jk_pool code is not thread safe so the internal state of the pool may be corrupted. Second, the map_uri_to_worker() function always calls jk_pool_reset() after mapping the URI. This means that if multiple URIs did get allocated into the pool without corruption, when the first thread finishes it will reset the pool. This may not create a noticeable problem because the memory in the pools isn't overwritten by a reset. If the other threads finish before another thread enters map_uri_to_worker() then nothing will fail. However, if another thread does enter map_uri_to_worker() then its call to jk_pool_strdup() will overwrite some of the previous contents of the pool and really bad things may happen. As I said, I don't have a solution, yet. Any solution would have to be platform independent and also work with all the Web servers that use the JK plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...). Suggestions? -- Marc - 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]
[j-t-c] Thread problem in jk_uri_worker_map.c
I've run into a threading problem in /j-t-c/native/jk/common/jk_uri_worker_map.c. The problem has been around for a long time, but I believe the changes checked in for version 1.15 on June, 27, 2003 made the problem worse. I have only been able to reproduce the problem on multi-processor machines running under a fairly heavy load. Unfortunately, I don't have a good solution, yet. The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in the map_uri_to_worker() function. The temp pool is used to store a copy of the incoming URI so that it can be altered to remove any jsessionid and to remove multiple adjacent / characters. The problem is that this single pool is shared by all the worker threads so if multiple threads are executing map_uri_to_worker() simultaneously there is a chance that the pool will get corrupted. This can happen in two ways. The jk_pool code is not thread safe so the internal state of the pool may be corrupted. Second, the map_uri_to_worker() function always calls jk_pool_reset() after mapping the URI. This means that if multiple URIs did get allocated into the pool without corruption, when the first thread finishes it will reset the pool. This may not create a noticeable problem because the memory in the pools isn't overwritten by a reset. If the other threads finish before another thread enters map_uri_to_worker() then nothing will fail. However, if another thread does enter map_uri_to_worker() then its call to jk_pool_strdup() will overwrite some of the previous contents of the pool and really bad things may happen. As I said, I don't have a solution, yet. Any solution would have to be platform independent and also work with all the Web servers that use the JK plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...). Suggestions? -- Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Object pooling performance
Another thing to consider when evaluating object pooling is the expected lifetime of the objects. On modern JVMs with generational memory stores, objects with a short lifespan (say the duration of a single HTTP request) will probably never leave the nursery. Pooling these kinds of objects usually degrades performance rather than improving it. I've just finished some performance research on Tomcat 3.2 (I know, I know...) and one of the things I found was that the o.a.u.MimeHeaders and related classes were a huge performance bottleneck. The existing code went to great lengths to avoid creating 'garbage' and the result was code that was very slow. I replaced it with a much simpler set of classes that basically ignored the GC impact and saw a 15% performance improvement under load. Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 9:25 AM To: Tomcat Developers List Subject: Object pooling performance Remy Maucherat wrote: Bill Barker wrote: Now, if we could only convince the Jasper developers of this ... ;-). Tag pooling is definitely not the same situation and use case as session pooling. Tag pooling *is* useful in many cases. There are a number of things to consider when evaluating the performance of object pooling. The performance hit of obtaining/recycling an object can be greater than instantiating a new object, it depends on the JVM. But you also have to consider the impact on GC. One big impact on performance of Tomcat is the frequency of and the time it takes to do incremental and Full GC's. Full GC's can be especially nasty. In most JVM's a Full GC freezes processing of requests by Tomcat. I would rather have a slight performance hit from recycling objects than see the frequency of Full GC's increase and the time they take increase. I saw a huge performance boost when recycling of JSP custom tags was implemented in Jasper. Most of that performance boost comes from reducing the frequency and length of GC's. To collect GC data add the -verbose:gc arg to java when you start Tomcat. Regards, Glenn - 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: Object pooling performance
I agree that the MimeHeaders example is not really an example of an object pool. I used it because it was a recent example that I found where avoiding GC at all costs was the wrong approach. Keep in mind, the utils stuff that I'm talking about is from TC3.2. I haven't looked at the latest TC code so it may be significantly better. The biggest problem with the TC3.2 MimeHeaders was that the algorithm required a large number of string comparisons and the number of comparisons increased geometrically as the number of headers increased. Rewriting the code to use a Hashtable and a better data structure for tracking headers with multiple values provided a significant performance benefit even though it created some garbage along the way. Since all of the objects were short lived, their allocation and collection from the nursery was very efficient and was far faster than all the string comparisons required by the original algorithm. The original performance problem stood out quite well in JProbe. The new code profiled faster and was then verified under a load test using real-world scenarios. Marc -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:18 PM To: Tomcat Developers List Subject: Re: Object pooling performance Marc Saegesser wrote: Another thing to consider when evaluating object pooling is the expected lifetime of the objects. On modern JVMs with generational memory stores, objects with a short lifespan (say the duration of a single HTTP request) will probably never leave the nursery. Pooling these kinds of objects usually degrades performance rather than improving it. I've just finished some performance research on Tomcat 3.2 (I know, I know...) and one of the things I found was that the o.a.u.MimeHeaders and related classes were a huge performance bottleneck. The existing code went to great lengths to avoid creating 'garbage' and the result was code that was very slow. I replaced it with a much simpler set of classes that basically ignored the GC impact and saw a 15% performance improvement under load. I find that *really* odd. We're not talking about an object pool here with the MessageBytes and the others, but rather a thread local direct reference. The code in utils seems very efficient to me, and even the worst JIT should look good tuning the array based algorithm of the HTTP/1.1 for your CPU. Using and manipulating Strings and stuff instead of that is dead slow in comparison. I confirmed with tests, as well as OptimizeIt (I don't know how real and accurate the OptimizeIt numbers are). I can't be so affirmative when it comes to real object pooling, such as tag pools. However, I believe that GC is a problem for scalability no matter how good the VM is on a large scale system. These kinds of pools can be very easily disabled or configured, so I don't see any problem. Remy - 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: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util RequestUtil.java
I don't think it really needed any discussion, but here's what's happening. I was a Tomcat 3.2.x developer and managed the releases of 3.2.2-4. I still have Tomcat 3.2 embedded in my product so I continue to support it after a fashion. Some day I'll get around to swapping it out with something else, but given my other time constraints and the fact that TC3.2 is actually doing everything I need it to do, the change has a rather low priority. One of the joys of working for a small ISV is that my day job often expands to include all of my evenings, nights, weekends, holidays, etc. For the last year or so I've been so busy with the day job that I've essentially vanished from the Jakarta scene. I didn't want to, it's just the way things worked out. Anyway, as I found bugs or performance issues in the TC3.2 code I fixed them, but until now they've just been sitting in my local machine. I had a choice, I could move all the TC3.2 code, including my new fixes, into my own source control and split from the Jakarta CVS repository or I could commit the changes. Putting the code back into the Jakarta project just seemed the right thing to do. Tomcat 3.2 is dead. Believe, no one knows this better than me since I was the one that put it sleep. There will never be another 3.2.x release. If anyone wants this stuff, they'll need to build it themselves, but that still seems better than keeping it to myself. Marc -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 7:44 PM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util RequestUtil.java Why is work being done on the tomcat_32 branch? I don't recall any discussion about this. Regards, Glenn [EMAIL PROTECTED] wrote: marcsaeg2003/07/01 14:07:43 Modified:src/share/org/apache/tomcat/util Tag: tomcat_32 RequestUtil.java Log: Several performance improvements. Revision ChangesPath No revision No revision - 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: Ever increasing heap size with Tomcat 3.2.3 !!!
Make sure you don't have lots of logging turned on. Tomcat logs message don't get written to the log files immediately. They go into a queue in memory and a low priority thread later flushes message from this queue to disk. If the server is really busy the log writer thread won't get to execute and messages will back up in the in-memory queue. When the load decreases the queue will be flushed and memory will be released. I've spent a fair amount of time running stress tests on Tomcat 3.2.x using JProbe and I have not seen any memory leaks. Marc Saegesser -Original Message- From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 11:34 AM To: [EMAIL PROTECTED]; tomcat-user Subject: Ever increasing heap size with Tomcat 3.2.3 !!! Hello, Before my manager insists that we switch to JRun, can any of the Tomcat developers help with a problem of an ever increasing heap size of the Tomcat java.exe. ?? (We are running Tomcat 3.2.3 and JRE1.3.1. and the IIS redirector) We are running a load test using LoadRunner scripts on some JSP and servlets that are running under Tomcat. The load is not all that heavy but the heap size of the Tomcat java.exe process keeps growing and growing. We modified the java command line to start with -Xmx128m to allow 128 MB of heap but we still max out after a day or so. We even modified one of our servlets to create a thread that runs Runtime.gc() every 30 seconds. The LoadRunner scripts just keep logging in the same 5 people via our authentication servlet so you would think memory use would level out at some point. Nothing we do seems to keep the heap size from growing. Are there known issues with Tomcat and heap size?? Doing a web search revealed numerous posts with people having similar problems so I believe there is a problem. The standard response these people receive is to increase the heap size via -Xmx But that seems like a band-aid rather than a real solution. That just delays the inevitable. Any insight as to how to keep the Tomcat process from grabbing more and more memory would be appreciated. Thanks, Keith -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT] Tomcat 3.2.4 Released
Jakarta Tomcat 3.2.4 is now available for download at http://www.apache.org/dist/jakarta/jakarta-tomcat/release/v3.2.4-beta-1 Tomcat 3.2.4 fixes bugs found since the Tomcat 3.2.3 release in July, 2001. See the RELEASE-NOTES file for details on bug fixes and changes in this release. Barring the need for critical security updates, this will be the last release of the Tomcat 3.2.x branch. Future Jakarta development for the Servlet 2.2/JSP 1.1 specification will be based on Tomcat 3.3. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New committer: Michael Smith
+1 Marc Saegesser -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 12:29 PM To: Tomcat Developers List Subject: [VOTE] New committer: Michael Smith Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- 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]
[RESULTS] Tomcat 3.2.4 release
Here are the results of the vote to release the tomcat_32 branch as Tomcat 3.2.4. I'll cut the release today. [8] +1. I agree with the proposal and I will help support the release. [3] +0. I agree with the proposal but I will not be able to help support the release. [0] -0. I don't agree with the proposal but I won't stop the release. [0] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Release Tomcat 3.2.4
The beta for Tomcat 3.2.4 is complete. During the beta there was one minor code change to fix bug 4577. This fix does not require another beta cycle. There are currently no Bugzilla bugs open against version 3.2.x. I propose that we release the current tip of the tomcat_32 branch as Tomcat 3.2.4. With the exception of critical bugs or sercurity updates I expect this to be the last release of the tomcat_32 branch. Fixes for non-critical or non-security bugs will be addressed in Tomcat 3.3.x releases. The vote will be open for 1 week and I will tally the results at that time. The proposal must receive at leaset three +1 votes and more +1s than -1s. - Vote to release the tomcat_32 branch as Tomcat 3.2.4. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Release Tomcat 3.2.4
Vote to release the tomcat_32 branch as Tomcat 3.2.4. [X] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] Release Tomcat 3.2.4
I think that 3.3 should be the officialy supported Servlet 2.2/JSP 1.1 release. Version 3.2.4 exists only because there were bug fixes and patches received after 3.2.3 was released and before 3.3 was released and these fixes should be made available to existing 3.2.4 users. Anyone just getting started with Tomcat should certainly be directed to 3.3 and 4.0. Marc Saegesser -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 8:56 AM To: Tomcat Developers List Subject: RE: [VOTE] Release Tomcat 3.2.4 +1 I've got a question about 3.2 against 3.3. Now that 3.3 is released, did 3.2 will be deprecated in favor of 3.3, since both of them support Servlet 2.2/JSP 1.1 ? Regards - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 3:53 PM To: [EMAIL PROTECTED] Subject: [VOTE] Release Tomcat 3.2.4 The beta for Tomcat 3.2.4 is complete. During the beta there was one minor code change to fix bug 4577. This fix does not require another beta cycle. There are currently no Bugzilla bugs open against version 3.2.x. I propose that we release the current tip of the tomcat_32 branch as Tomcat 3.2.4. With the exception of critical bugs or sercurity updates I expect this to be the last release of the tomcat_32 branch. Fixes for non-critical or non-security bugs will be addressed in Tomcat 3.3.x releases. The vote will be open for 1 week and I will tally the results at that time. The proposal must receive at leaset three +1 votes and more +1s than -1s. - Vote to release the tomcat_32 branch as Tomcat 3.2.4. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser -- 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: Can someone commit this minor fix?
I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Can someone commit this minor fix?
Mike, [I tried sending this privately, but it bounced.] I just got caught up on the rest of the messages in tomcat-dev and it looks like this patch doesn't do what you expect. Mod_jk doesen't handle wildcards per se. It only knows two kinds of mappings JkMount /path/* and JkMount *.ext The way code is written, doing JkMount /path/*j_security_check will actually map all requests to /path/* to Tomcat. Now, that isn't necessarily a bad thing, and unless your application has lots of static data that would be better served through Apache, I think its safer to route all requests to resources inside the web application through Tomcat. All of my applications now just do a JkMount /app/* AJP13. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 2:08 PM To: [EMAIL PROTECTED] Subject: Re: Can someone commit this minor fix? Hi Marc, The diff to use is Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/Apache Config.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +/*j_security_check ajp12); The other one you have is missing the / before *j_security_check Thanks again! -Mike - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, November 01, 2001 10:54 AM Subject: RE: Can someone commit this minor fix? I'll get into Tomcat 3.2.4 before the final release. Marc Saegesser -Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 01, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: Can someone commit this minor fix? The following fix enables form-based authentication to work with Apache + Tomcat. Can someone add this to tomcat 3.2? Thanks! -Mike Jennings Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/tas k/Attic/ApacheConfig.java,v retrieving revision 1.12.2.2 diff -r1.12.2.2 ApacheConfig.java 202a203 mod_jk.println(JkMount /*j_security_check ajp12); 289a291 mod_jk.println(JkMount + path +*j_security_check ajp12); -- 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: Where's the 3.3 release build?
I think the web site got messed up and older version of the binindex.html got posted. I updated the site last night for the 3.2.4 beta 1 release and put the 3.3 links back in at the same time. Marc Saegesser -Original Message- From: Schreibman, David [mailto:[EMAIL PROTECTED]] Sent: Friday, October 26, 2001 6:11 PM To: '[EMAIL PROTECTED]' Subject: Where's the 3.3 release build? Hi, Just wondering what happened to the 3.3 release build at http://jakarta.apache.org/site/binindex.html I'm pretty sure I got a copy from there last week but it's gone now. One of my co-workers was looking to install it today and just came by to ask me about this. Thanks, -David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Tomcat 3.2.4 release
I propose that we release the tip of the tomcat_32 branch as Tomcat 3.2.4. Since the 3.2.3 release there have been several bug fixes and patches applied to the branch and these should packaged as a public release. I will be the release manager. After this release I expect that all future Tomcat 3.x development will be based on Tomcat 3.3. The release plan has been checked into cvs and a copy is attached. Please review the plan reply with your vote. -- Vote: Tomcat 3.2.4 Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- Marc Saegesser RELEASE-PLAN-3.2.4
RE: [PROPOSAL] Tomcat 3.2.4 release
Regarging JAXP, if I understand correctly, I can build with and ship the jaxp.jar and crimson.jar from JAXP-1.1 but users can still run with the older jaxp.jar and parser.jar from jaxp-1.0.1, right? I have two concerns. First I want to preserve the ability for existing users to upgrade to 3.2.4 by simply copying the new webserver.jar file into tomcat/lib. Second, because of the class loader issues in 3.2.x, webapps see the classes from tomcat/lib before they see the ones in their WEB-INF/lib directory. Thus replacing the parser in tomcat/lib could have unintended side effects on existing applications. I don't have any problem shipping with the later JAXP stuff as long as we can still run with the older version that we've shipped with in the past. I'll take a look at the diffs between the Jdk12Interceptor in tomcat_32 and 3.3 and how it looks. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 19, 2001 1:08 PM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Tomcat 3.2.4 release +1 Would it be possible to also include a recent Jaxp ( xerces is also fine ) and add the Jdk12Interceptor ( that sets context class loader ) in the default server.xml ? ( with instructions on how to remove it on JDK1.1 ) ? There are so many SOAP, etc problems that are resolved by just adding the module, and only few people knows about this... Costin On Fri, 19 Oct 2001, Marc Saegesser wrote: I propose that we release the tip of the tomcat_32 branch as Tomcat 3.2.4. Since the 3.2.3 release there have been several bug fixes and patches applied to the branch and these should packaged as a public release. I will be the release manager. After this release I expect that all future Tomcat 3.x development will be based on Tomcat 3.3. The release plan has been checked into cvs and a copy is attached. Please review the plan reply with your vote. -- Vote: Tomcat 3.2.4 Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- Marc Saegesser
RE: [PROPOSAL] Tomcat 3.2.4 release
I suppose I should vote for my own proposal. -- Vote: Tomcat 3.2.4 Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- Marc Saegesser
RE: [VOTE] New Committer
+1 Marc Saegesser -Original Message- From: Christopher Cain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 11:02 PM To: [EMAIL PROTECTED] Subject: [VOTE] New Committer I would like to nominate Patrick Luby [EMAIL PROTECTED] for committer status. His recent contributions include several security-manager-related patches and documentation help, and appears keen to tackle the Admin Apps functionality as well. I think he would make an excellent addition to the team. Votes please? - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
RE: [PATCH] SimplePool.java
I'll make the change to the tomcat_32 branch.
Marc Saegesser
-Original Message-
From: Renato Weiner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 2:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] SimplePool.java
What about Tomcat 3.2.3 ? There are the same lines of
code...
--- Schreibman, David [EMAIL PROTECTED]
wrote:
Here's a simple tweak that clears out references to
objects that are removed
from the pool. The current code can delay garbage
collection for objects
that are removed from the pool but not returned.
The diff is against 3.3-rc1
-David
--- SimplePool.java.orig Thu Oct 4 10:14:51 2001
+++ SimplePool.java Thu Oct 4 10:54:08 2001
@@ -132,6 +132,7 @@
synchronized( lock ) {
if( current = 0 ) {
item = pool[current];
+ pool[current] = null;
current -= 1;
}
if( debug 0 )
__
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month.
http://geocities.yahoo.com/ps/info1
RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
It probably isn't a big deal now. I've got the .dsp file working now. Once I'm satisfied everything is OK I'll commit the changes and also export a Windows makefile so that I can build without using the damned IDE. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Wednesday, October 03, 2001 3:30 AM To: [EMAIL PROTECTED] Subject: Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows Justin Erenkrantz wrote: On Tue, Oct 02, 2001 at 01:24:53PM -0500, Marc Saegesser wrote: I'll grab the latest CVS and see how that works. The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal and autoconf. Cygwin includes all of these except libtool. I built it and installed it into /usr/local/bin and bad things happened. I put it into /usr/bin and things ran fine. Ah, that's jk-specific. It might be a good idea to try to remove the automake dependency if at all possible as we don't require it for httpd. That is possible - But that means to commit some automake generated files or to duplicate these files - All of the others are required for Apache 2.0. Pier has a good build system with 2.0 for mod_webapp. =) -- justin
RE: SCRIPT_NAME and PATH_INFO with extension mapping
I agree that prohibitting PATH_INFO for extension mapped servlets is not good. But, a lot of people have been throwing things like this violates the HTTP specification or this violates the HTML specification. Would someone please show me where either of these specifications makes any mention of PATH_INFO? PATH_INFO is a CGI concept and CGI is a finalist for the least specified specification award. Also, the CGI specification does not describe any methods for mapping URLs to CGI applications, this is a function of the Web server, so it doesn't really help much in the debate over how PATH_INFO should be treated with extension mappings vs. prefix mappings. That said, what little information is provided in the specification would lend credence to the side (my side, actually) that PATH_INFO should be available in either case. Here's the section on the PATH_INFO environment variable: --- - PATH_INFO The extra path information, as given by the client. In other words, scripts can be accessed by their virtual pathname, followed by extra information at the end of this path. The extra information is sent as PATH_INFO. This information should be decoded by the server if it comes from a URL before it is passed to the CGI script. --- Since this stuff has *nothing* to do with HTTP or HTML, the servlet specification is free to specify what getPathInfo() returns however it pleases. The examples provided on this thread provide good reasons why the existing specification is lacking and I think it should be changed. Lets just understand why it needs changed and not through non-existent specification violation claims. Marc Saegesser -Original Message- From: Christopher Cain [mailto:[EMAIL PROTECTED]] Sent: Monday, October 01, 2001 1:04 AM To: [EMAIL PROTECTED] Subject: Re: SCRIPT_NAME and PATH_INFO with extension mapping Quoting Jon Stevens [EMAIL PROTECTED]: I'm a member of JSR-053. I will work to change it for the next release of the spec. Cool. From what I've heard, the entire TC developer community is behind you 100%. Hell, even Costin agrees with you ... now *that's* truly a red letter day =) Needless to say, this has a serious impact on Turbine's ability to function. It is complete bullshit that it works fine if defined through a servlet, but not with extension mapping. This works: http://www.foo.com/context/servlet/Turbine/template/Foo.vm This doesn't: http://www.foo.com/context/Foo.vm/bar/ack As a result, there is no way for Turbine to work properly with extension mapping because it relies on passing information in the PATH_INFO and not QUERY_STRING because of the need for search engines to be able to archive website information. That sucks, bro. I empathize. I don't know that much about Turbine, to be honest, but would my proposed change to respecting the HTML spec for static content help out with the second case above? I know it's not really static, but if it's outside of the explicit servlet area, would it fall under the auspices of the servlet behavior or the static behavior? Or am I just reaching for a loophole? :) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
Here's an update on where I stand right now on building/running mod_jk for Apache 2.0 beta 16. I spent a considerable amount of time on the automake route. Cygwin doesn't include libtool by default so I had to download and build that. I then ran into an odd build problem that turned out to be caused by having installed my new libtool stuff into a different directory then where automake was already installed. Once I fixed that I was able to run ./buildconf.sh and ./configure on Win2000/Cygwin. This comes close to working, but still misses some things. I don't know enough yet about the autmake stuff to deal with this right now. Maybe I'll get back to it again later. I then took a deeper look at the mod_jk.dsp file. I discovered that some hand edits a while back broke the file's structure. Once I fixed those up I was able to load the .dsp into Dev Studio. Several of the include and library paths have changed in 2.0 beta 16 so I had to fix those up. I now have an environment that builds mod_jk for apache 1.0 beta 16! I'll commit these changes later today. Now I'm getting some odd behaviour when I use the module. The request seems to be forwarded to Tomcat and the response comes back, but it doesn't appear in the browser. I use telnet to issue the request I get back what looks like a valid response. I'll investigate this later today. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Friday, September 28, 2001 5:18 PM To: [EMAIL PROTECTED] Subject: [J-T-C] Building mod_jk for Apache 2.0/Windows I'd like to start experimenting with Tomcat and Apache 2.0. The Apache 2.0 code in the tomcat_32 branch appears to be quite out of date. I tried building the stuff in j-t-c, but the .dsp file won't load in DevStudio 6 and I don't have the libtools stuff for doing a command line build. If someone could give me some pointers on getting this building on the Win32 platform (I've got cygwin) I'd appreciate it. Also, once I've got a build environment, is there anyplace I can lend a hand? Marc Saegesser
RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
Nope, no error messages. The first thing I ran into was that WIN32 needs to be defined for Win32 compiles. I manually added that to CFLAGS in all the generated Makefiles and things got further, but there were still problems (I don't recall exactly what at the moment). At that point I decided to give up and work on the .dsp file. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of jean-frederic clere Sent: Tuesday, October 02, 2001 12:20 PM To: [EMAIL PROTECTED] Subject: Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows Marc Saegesser wrote: Here's an update on where I stand right now on building/running mod_jk for Apache 2.0 beta 16. I spent a considerable amount of time on the automake route. Cygwin doesn't include libtool by default so I had to download and build that. I then ran into an odd build problem that turned out to be caused by having installed my new libtool stuff into a different directory then where automake was already installed. Once I fixed that I was able to run ./buildconf.sh and ./configure on Win2000/Cygwin. This comes close to working, but still misses some things. I don't know enough yet about the autmake stuff to deal with this right now. Maybe I'll get back to it again later. Any error messages from automake? - I will try at home with winnt - I then took a deeper look at the mod_jk.dsp file. I discovered that some hand edits a while back broke the file's structure. Once I fixed those up I was able to load the .dsp into Dev Studio. Several of the include and library paths have changed in 2.0 beta 16 so I had to fix those up. I now have an environment that builds mod_jk for apache 1.0 beta 16! I'll commit these changes later today. Now I'm getting some odd behaviour when I use the module. The request seems to be forwarded to Tomcat and the response comes back, but it doesn't appear in the browser. I use telnet to issue the request I get back what looks like a valid response. I'll investigate this later today. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Friday, September 28, 2001 5:18 PM To: [EMAIL PROTECTED] Subject: [J-T-C] Building mod_jk for Apache 2.0/Windows I'd like to start experimenting with Tomcat and Apache 2.0. The Apache 2.0 code in the tomcat_32 branch appears to be quite out of date. I tried building the stuff in j-t-c, but the .dsp file won't load in DevStudio 6 and I don't have the libtools stuff for doing a command line build. If someone could give me some pointers on getting this building on the Win32 platform (I've got cygwin) I'd appreciate it. Also, once I've got a build environment, is there anyplace I can lend a hand? Marc Saegesser
RE: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows
I'll grab the latest CVS and see how that works. The buildconf.sh in jk/native/Apache-2.0 runs libtoolize, automake, aclocal and autoconf. Cygwin includes all of these except libtool. I built it and installed it into /usr/local/bin and bad things happened. I put it into /usr/bin and things ran fine. Marc Saegesser -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 1:12 PM To: [EMAIL PROTECTED] Subject: Re: [J-T-C] Update: Building mod_jk for Apache 2.0/Windows On Tue, Oct 02, 2001 at 10:29:41AM -0500, Marc Saegesser wrote: Here's an update on where I stand right now on building/running mod_jk for Apache 2.0 beta 16. Please don't use Apache 2.0.16. Use the latest version from CVS. Also, I'm not sure where automake is coming from - we don't use that. Perhaps, you mean autoconf? We also revamped the build system well after the 2.0.16 timeframe. Hopefully, things might be smoother with the latest version. -- justin
RE: URI handling in tomcat 3.2.3
DOH! I don't believe I did that. I cutpasted the URI from the wrong spot. Here's the real trace. Note that Apache 1.3.19 does decode the %2f characters but now returns a 404 error instead of sending the decoded string as PATH_INFO. I've attached two traces, one that demonstrates a working PATH_INFO test and a second that uses %2f and fails. --- GET /cgi-bin/dumpenv.bat/pathinfo COMSPEC=C:\WINNT\system32\cmd.exe DOCUMENT_ROOT=c:/program files/apache group/apache1.3.19/htdocs PATH=C:\Apropos\Sybase\Adaptive Server Anywhere 6.0\win32;C:\Apropos\java\bin;C: \Apropos\java\bin\classic;C:\Apropos\bin;C:\Apropos\tcl\bin;c:\java\jdk1.4\b in;c :\java\jdk1.4\bin;D:\Apropos\Sybase\Adaptive Server Anywhere 6.0\win32;C:\Progra m Files\Sybase\Adaptive Server Anywhere 6.0\win32\win32;C:\WINNT\system32;C:\WIN NT;C:\WINNT\System32\Wbem;C:\ClearCase\bin;.;C:\Program Files\Symantec\pcAnywher e;c:\tools\rebol;C:\Program Files\Support Tools\;C:\IMNnq_NT;C:\PROGRA~1\TCL\bin PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS PROMPT=$P$G REMOTE_ADDR=127.0.0.1 REMOTE_PORT=1269 SCRIPT_FILENAME=c:/program files/apache group/apache1.3.19/cgi-bin/dumpenv.bat SERVER_ADDR=127.0.0.1 [EMAIL PROTECTED] SERVER_NAME=msaegesserlpt SERVER_PORT=8081 SERVER_SIGNATURE=ADDRESSApache/1.3.19 Server at msaegesserlpt Port 8081/ADDRE SS SERVER_SOFTWARE=Apache/1.3.19 (Win32) mod_jk SystemRoot=C:\WINNT WINDIR=C:\WINNT GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/0.9 REQUEST_METHOD=GET QUERY_STRING= REQUEST_URI=/cgi-bin/dumpenv.bat/pathinfo SCRIPT_NAME=/cgi-bin/dumpenv.bat PATH_INFO=/pathinfo PATH_TRANSLATED=c:\program files\apache group\apache1.3.19\htdocs\pathinfo Connection to host lost. --- --- GET /cgi-bin/dumpenv.bat/http:%2f%2ffubar !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE404 Not Fou nd/TITLE /HEADBODY H1Not Found/H1 The requested URL /cgi-bin/dumpenv.bat/ http://fubar was not found on this server.P HR ADDRESSApache/1.3.19 Server a t msaegesserlpt Port 8081/ADDRESS /BODY/HTML Connection to host lost. --- Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 20, 2001 5:13 PM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 You only use http:// in the GET request if you're talking to a proxy server. That's probably why you got the bad request error, not because of the %2f. You should try: GET /cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 -jh- Marc Saegesser wrote: Oops, minor correction. Apache actually returns 400 Bad Request Here's the telnet session GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 server: msaegesserlpt HTTP/1.1 400 Bad Request Date: Thu, 13 Sep 2001 13:51:21 GMT Server: Apache/1.3.19 (Win32) mod_jk Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18b !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE400 Bad Req uest/TITLE /HEADBODY H1Bad Request/H1 Your browser sent a request that th is server could not understand.P client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbarP HR ADDRESSApache /1.3.19 Server at msaegesserlpt Port 8081/ADDRESS /BODY/HTML 0 Connection to host lost. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 8:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way
RE: URI handling in tomcat 3.2.3
Jason, Lars, all, I've been investigating the normalized URL, encoded special characters, etc. issues with Tomcat 3.2.3 and I think I have a solution that both maintains the required level of security and allows the kind of thing that Lars and Jason are looking for. I've attached a patch that I would appreciate reviewed by committers to make sure I'm not missing something. What I've done is changed the existing RequestUtil.URLDecode() to prevent the decoding of some additional characters. There was already code there to prevent '/' and '\0' and I added the other protected chars '\\', '.' and '%'. I then removed the draconian test to 404 any URL containing these special chars. If a URI contains encoded special characters from this list then these characters *remain encoded* in the resulting URI. For example /fu/ba+r -- /fu/ba r /fu%2fba+r -- /fu%2fba r I've tested this with all the 'bad' URLs that used to expose JSP source or avoid security constraints and everything works fine. Tomcat will still normalize all URIs as soon as they arrive in the container (sorry Jason). To avoid normalizing data passed in the pathinfo you will need to encode the path characters and then have your servlet URL decode the path info. For example, assuming /fubar/* is the prefix mapping, http://server/fubar/http:%2f%2fURLInPathInfo or http://server/fubar/http:%2f/URLInPathInfo will return path info that can be decoded URLDecoder.decode() into http://URLInPathInfo. Comments? Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:49 PM To: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references inside a query (why should it) I belive that there are many more use-cases where using URIs to represent hierachical names that do not map to files is desirable, espacialy in a servlet environment. In httpd, which's main work consists of serving file-system resources this might be viewed differently Cheers, Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop
RE: URI handling in tomcat 3.2.3
I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: URI handling in tomcat 3.2.3
Oops, minor correction. Apache actually returns 400 Bad Request Here's the telnet session GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1 server: msaegesserlpt HTTP/1.1 400 Bad Request Date: Thu, 13 Sep 2001 13:51:21 GMT Server: Apache/1.3.19 (Win32) mod_jk Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18b !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE400 Bad Req uest/TITLE /HEADBODY H1Bad Request/H1 Your browser sent a request that th is server could not understand.P client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbarP HR ADDRESSApache /1.3.19 Server at msaegesserlpt Port 8081/ADDRESS /BODY/HTML 0 Connection to host lost. Marc Saegesser -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 8:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: URI handling in tomcat 3.2.3 I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. In fact we lifted our restriction on encoded special characters straight from Apache HTTPD. In your example URL, if /app/UCB was a CGI script then you would still get a 404 on Apache (at least on Apache 1.3.19 which is what I tested with). If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 5:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: URI handling in tomcat 3.2.3 Hi everyone, we were in progress of moving our project to tomcat 3.2.3 when we came accross the new handling of URIs (release-notes sec. 7.2). Since we are using the URI to transport other hierarchical information then filesystem paths, we have the feeling, that this kind of functionality belongs to the default servlet serving filesystem requests. Especialy the fact that %25, %2E, %2F and %5c inside an URI lead to a 404 error seems to somewhat strange. For Example: http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource would be rejected, before app has teh possibilty to look at the request and ...hier://address/myfile... would be normalized to hier:/address. We are perfectly aware of the security concerns behind these changes. However, they only apply when serving resources from the filesystem. A URL's path-components however are in no way bound to the representaion of filesystem paths.(After all, the U in URL stands for universal :) RFC 2396 states that '/' in an URI has another semantic meaning then %2F in an URI. The '/' seperates path-components, while the %2F means a slash character in a path-component. When such an URI is mapped to a filesystem this would denote a filename that contains a slash. When the system does not allow for such names, it is the responsebilty of the filesystem servlet to report an error (404 since such a file must not exist on unix for example). What are your opinions on this? Cheers -Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: URI handling in tomcat 3.2.3
Lars, I agree with you. These encoded characters should be allowed in URIs and disallowing them is a hack. Like I said, I think the approach sucks. We were faced with a very serious security problem that had to be addressed very quickly and the decision was made that it was better to forbid certain 'odd' URIs in order to guarantee that resources that the specification *requires* to be protected were indeed protected. We need to look into how to solve the security problems without forbidden valid URIs, but right now I'm about the only one around paying much attention to the tomcat_32 branch so I don't know what kind of time frame wold be involved to get this changed. I do know that the solution will not be trivial. I mentioned Apache httpd only to show that our approach to this problem is in-line with that taken by other industry leading products. We should not (and I think have not) blindly follow httpd (it does a few other things that disagree with). Patches or discussion on how to go about fixing this are certainly welcome! Marc Saegesser -Original Message- From: Lars Oppermann [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:23 AM To: [EMAIL PROTECTED] Subject: Re: URI handling in tomcat 3.2.3 Hi Marc, Thanks for you reply... Marc Saegesser wrote: I agree that this URI handling sucks. I'm the one that committed the change that made it happen and I still think it sucks. However, allowing these encoded characters opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? Also, even if TC 3.2.x allowed these characters, the resulting URL wouldn't be portable because several other web servers impose the same restrictions. [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. If you need to pass this sort of data to a servlet (or CGI) the most portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references inside a query (why should it) I belive that there are many more use-cases where using URIs to represent hierachical names that do not map to files is desirable, espacialy in a servlet environment. In httpd, which's main work consists of serving file-system resources this might be viewed differently Cheers, Lars -- -- Lars Oppermann [EMAIL PROTECTED] Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop
RE: [VOTE] Bug Notification E-Mails
-1 Marc Saegesser -Original Message- From: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 2:03 PM To: [EMAIL PROTECTED] Subject: Re: [VOTE] Bug Notification E-Mails Christopher Cain [EMAIL PROTECTED] wrote: Also, while I might technically have the ability to call for a vote on anything, it's bad form to call a vote on something that you personally cannot make happen. Since I do not have the ability to set up a new mailing list, it would be the equivalent of me forcing more mailing list duties on Pier. Basically, I did the most that I could do. The only people who could realistically called for a vote on a new mailing list are Jon (who isn't in favor of it), Pier (who I think is fed up with the whole business at this point :), and Craig (who didn't say one way or the other). As I said, I don't personally care how they get into my inbox, so long as they do. So in calling a vote, I simply played the percentages. Ok, so since I need to try to be the nice guy over here, let's do it this way... It seems apparent that the mailing list want to be notified of bugs (lots of +1 and no -1), so this is a simple one [ ] +1 - I want all messages to a new tomcat-bugs mailing list [ ] -1 - I want all messages to tomcat-dev (I'd propose this is a non vetoing vote, so, majority wins) Pier
RE: Tomcat 3.2.3 and getPathInfo
1) A URL identifies a resource. It doesn't matter whether the resource is a static file, CGI, servlet, JSP, ASP or anything else, it simply names a resource. To say that some pieces of the URL should be normalized while other pieces should not goes against this concept. Any two URLS that name the same resource can be considered identical and can freely be rewritten as long as they continue to name the same resource. Browsers do this all the time and I assume that proxy servers may as well. 2) The URLs http://server/a/b/../c, http://server/a/./c and http://server/a/c all obviously refer to the same resource. Now assume that /a/c/* is a prefix mapping for a servlet, because all these URLs refer to the same resource they must all mapp to the servlet. By normalizing the URL we don't alter the resource being requested and we can now do the comparison to test for a matching prefix. Now assume that the /a/* is a prefix mapping for a servlet. The same three URLs still name the same resource. What should the servlet expect to see in path info? I supposed it might expect any one of /b/../c, /./c or /c, but since those all map to the same thing the servlet should still return the same result. If it doesn't then it has created more than one resource with the same name. Every server that I tested returned a path info of /c (the fully normlized version). 3) The security problem comes not from the servlet prefix mapping but a related issue of security-constraints specified by a url-pattern. If /a/b/* is protected then URLs like http://server/a/./b/c and http://server/a/c/../b/d both refer to resources withing the protected area and must not be served unless the user is authenticated. Normalizing these URLs make the url-pattern comparison possible. 4) Now, for the case of two adjacent slash characters. It comes down to whether the URLs http://server/a/b/c, http://server/a/b//c and http://a//b/c refer to the same resource or not. Every implementation I've seen treats an empty hierachy part identical to no hierarchy part. All of these URLs refer to the same resource, regardless of whether the resource comes from a static file or a servlet. If /a/* is the prefix mapping for a servlet then, just like in 2) above, servlet a must expect that it can receive normalized path info and if it doesn't receive one it should normalize it anyway so that it serves the same resource regardless of how normalized the initial URL was. If /a/b/* is a security contraint then all of these URLs refer to a protected resource. 5) A servlet or CGI script should not expect to be able to receive non-normalized information in path info. URLs are subject to rewritting at several times: by the originating browser, intervening proxy servers, http servers and the servlet container. If a servlet or CGI needs data that *must not* be subject to URL normalization then it *must* be passed in the query string. 6) This behaviour did change between 3.2.2 and 3.2.3, but this behaviour is not protected by any specification. Yes the change can break existing (non-portable) code and yes, I'm sorry, it does break the code in your book. But, IMHO, that code is not a good example of the usage of getPathInfo() and it is not portable. 7) You are welcome to submit a patch that provides the functionality that your looking for as long as you can make absolutely certain that no resource protected by a security contraint can be inadvertantly served by any oddly formated URL. I won't commit that patch because I think its a bad idea, but you might find someone here who will commit it. Actually I notice that your listed as a Tomcat committer so you could just do it yourself. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 12:07 AM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo I'd still like to see Tomcat allow the slashes. Here's my argument: * Allowing two adjacent slashes to remain is not a security risk * The Apache Web Server allows the slashes to remain * Tomcat used to allow the slashes to remain * Code (like mine) which used to work with Tomcat is now breaking * It's breaking a book example too, which may cause lots of bug reports (to both of us) * Unless the spec says to normalize beyond what's necessary, Tomcat shouldn't normalize beyond what's necessary -jh- Marc Saegesser wrote: After looking into this further I've changed my mind. I've tried this using other web servers (iPlanet, IIS 4.0 and 5.0) and in all cases the value in PATH_INFO has been fully normalized including removing adjacent / characters. IIS gets the contents of PATH_INFO wrong, but it is fully normalized. The CGI 1.1 specification is silent on this topic (like it is on most other important details). I think we should leave Tomcat as it currently is in 3.2.3. If you need to pass data to a servlet in the URL
RE: [VOTE] New commiter Ryan Bloom
+1 Marc Saegesser -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 11:24 AM To: [EMAIL PROTECTED] Subject: [VOTE] New commiter Ryan Bloom I would like to propose Ryan Bloom as commiter in Tomcat, and particulary on jakarta-tomcat-connector. Ryan is one of the dev leader in Apache 2.0 and contributed many patch for both mod_jk and mod_webapp, showing us that connectors avoid politics :) Vote, please - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: Tomcat fan-sites, plushies, etc
Actually, the tomcat_32 nightlies are very stable. I'm about the only one still committing much to that branch and I've been pretty slow these days. All the stuff going in there are minor bug fixes with little risk of breaking existing functionality. The nightlies don't get the large scale user testing that a beta drop gets, but with a little testing in my own application environment I wouldn't hesitate to run a tomcat_32 nightly in production. Marc Saegesser -Original Message- From: Christopher Cain [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 11:16 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat fan-sites, plushies, etc Quoting Deacon Marcus [EMAIL PROTECTED]: p.s. Great work. Great-great-great work. I love you guys. Always remember I have enough faith in your work to use your latest beta versions in production environment :) Ahhh ... is that all? If you _really_ had faith in us, you'd use the nightlies in production. And if you _really_, *really* had faith in us, you'd compile from cvs at random and use *that* in production =) (Obligatory parental warning label: That was a joke. _Please_ don't use a nightly or cvs build in a serious production environment ... unless you like to kiss the razor's edge ;-) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Cornelle */
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util SessionIdGenerator.java
We're talking about 5-15 seconds, so this really isn't a big deal. Tomcat could not previously serve a request that generated a session id without initializing the PRNG and we got several complaints about how long it took to process the first request (due to seed generation). The original solution was to generate our own seed, but that turned out to be cryptographically weak so we need to switch back to the default seed generator. That leaves us with three choices: 1) Initialize the PRNG as part of the container initialization, before we start processing requests. 2) Initialize the PRNG when the first session id is generated. 3) Initiaiize the PRNG on a separate thread that is created during the container initializaion. We can start processing requests before this thread completes, but we have to synchronize the session id generation to make sure the PRNG initialization is complete before we generate any new session. All of these solutions works. We already know that lots of people (including myself) complained about number 2 (that's the way it used to work). Option 3 is more complicated and all it buys you is that non-session requests can be processed in the first few seconds that the container is running. Option 1 is simple, does not involve new threads or thread synchronization and the only down side is that we delay processing requests for a few seconds. In my opinion, option 1 made the most sense. Marc Saegesser -Original Message- From: David Rees [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 11:51 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util SessionIdGenerator.java On Wed, Sep 05, 2001 at 02:42:14AM -, [EMAIL PROTECTED] wrote: marcsaeg01/09/04 19:42:14 Modified:src/share/org/apache/tomcat/startup Tag: tomcat_32 Tomcat.java src/share/org/apache/tomcat/util Tag: tomcat_32 SessionIdGenerator.java Log: Switch back to the default PRNG seed generator to avoid security weakness in the manual seed generator. The PRNG is now initialized when the container starts so that we don't take the hit on the first request. Submitted by: Kevin E. Fu ([EMAIL PROTECTED]) Does this prevent Tomcat from accepting requests until after the PRNG is initialized? If so, IMHO Tomcat should accept requests ASAP, even if it can't completely serve them until the PRNG is accepted. Isn't that better than rejecting requests? -Dave
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util SessionIdGenerator.java
I went back and forth several times last night about removing the
get/setEntropy() methods. They were added with the code to set the seed and
they did serve a valid purpose at that time, but they don't serve much use
now.
I can't remove them because people might actually be using the methods (I
really doubt it, but they might) and that would break they code. What I'll
do is make them deprecated in this release to discourage people from
starting to use them.
Marc Saegesser
-Original Message-
From: Christopher Cain [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 12:31 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util
SessionIdGenerator.java
[snip]
First off, let me say that the above patch is a _really_ good
idea, as far as
letting the PRNG default to its own entropy-collection routine, so that
definitely need to be done IMO.
Now I know that what I am about to suggest falls under the
category of a trying-
to-save-users-from-themselves enhancement, and not an actual bug
fix as would
be appropriate for the 3.2 branch, but it never hurts to offer, right? =)
The problem (which has nothing to do with the above patch other
than having
brought the existing algorithm to my attention :-) is that the
for{} loop here
serves no real purpose. If the user passes an insecure seed
value, this for{}
loop provides absolutely no additional security value. Now it
doesn't really
degrade security either, which is why it's not really a bug per
se. My only
concern is this: It's probably not patently obvious to someone
without prior
cryptography experience that this additional pass is merely
smoke-and-mirrors
with no practical benefit. I also know that users are _always_
trying to find
shortcuts around the delay in Java's PRNG initalization (in fact,
that alone
accounts for at least 50% of the security flaws in Java crypto
based on my
experience). My concern is that people will start investigating
startup delays,
track it down to this, see that the internal Tomcat code is doing
some kind of
mumbo-jumbo with a user-provided seed value, try it (to find that
they shaved
~10 seconds off their startup), and assume that whatever Tocmat
is doing is
probably sufficient for my application. IMHO, it's much safer
to just remove
this for{} loop voodoo in order to avoid the implication that it
does anything
meaningful.
Anyway, that's my take. Usually, bad crypto is worse than no
crypto at all. In
this case, it will probably result in a few less people trying to
outsmart the
PRNG.
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
*---Cornelle
*/
RE: [VOTE] Release Plan for Apache Tomcat 4.0 (final release)
-- Release Plan for Apache Tomcat 4.0 (final release) -- [ ] +1I am in favor of this plan, and will help [X] +0I am in favor of this plan, but am unable to help [ ] -0I not in favor of this plan [ ] -1I am opposed to this plan, and my reason(s) are: One of these days I'll put tomcat_32 behind me and move on to some of this new stuff. Congratulations to everyone who has worked on this. You guys have done really great job. Marc Saegesser
RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash
Costin, Sure, I'll take care of it today. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, August 31, 2001 12:13 AM To: [EMAIL PROTECTED] Subject: RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash On Thu, 30 Aug 2001, Marc Saegesser wrote: The patch looks good and seems to work OK after I configured my tomcat service to attempt restarts on failures. I hacked Tomcat to croak on start up and the SCM correctly attempted a single restart and then quit. Hi Marc, Could you check it in the main branch too ? Costin
RE: Tomcat 3.2.3 and getPathInfo
After looking into this further I've changed my mind. I've tried this using other web servers (iPlanet, IIS 4.0 and 5.0) and in all cases the value in PATH_INFO has been fully normalized including removing adjacent / characters. IIS gets the contents of PATH_INFO wrong, but it is fully normalized. The CGI 1.1 specification is silent on this topic (like it is on most other important details). I think we should leave Tomcat as it currently is in 3.2.3. If you need to pass data to a servlet in the URL and that data *must not* be susceptible to URL normalization then the data *must* be in the query string. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 8:45 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo Marc Saegesser wrote: Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Perfect, then my issue (at least) would be solved. -jh-
RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash
The patch looks good and seems to work OK after I configured my tomcat service to attempt restarts on failures. I hacked Tomcat to croak on start up and the SCM correctly attempted a single restart and then quit. The patch has been committed. The native code doesn't get built for the nightly builds so this won't show up in a distribution until Tomcat 3.2.4 (and I haven't worked out a schedule for that yet). Marc Saegesser -Original Message- From: Dave Ringoen [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 4:55 PM To: '[EMAIL PROTECTED]' Cc: Chien-Ming Huang; Brian Enright; Rob Webb; Patti Vrobel; Steven Velez Subject: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash We're using Tomcat at our company with considerable success, but discovered that if java.exe crashes for some reason, the Tomcat service won't restart automatically. I diagnosed the problem and came up with this discovery and a proposed fix. jk_nt_service.exe exits too gracefully if the java.exe process dies, notifying the Service Control Manager that it is shutting down. When Service Control Manager receives the shutdown message, it does not restart the service. It assumes that the service was supposed to be shut down. This patch makes jk_nt_service exit more abruptly without notifying SCM. With this patch, SCM will correctly initiate a restart of the Tomcat service. I couldn't file this in Bugzilla because Bugzilla was down. Thanks for your consideration on this patch. I'm very impressed with the Tomcat development approach and process. Dave Ringoen Alventive, Inc. cvs diff -u jk_nt_service.c (in directory C:\Temp\tomcatsrcnightly\jakarta-tomcat\src\native\mod_jk\nt_service) Index: jk_nt_service.c === RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_servic e.c, v retrieving revision 1.3 diff -u -r1.3 jk_nt_service.c --- jk_nt_service.c 2001/04/24 08:49:46 1.3 +++ jk_nt_service.c 2001/08/30 18:05:02 @@ -535,6 +535,11 @@ /* * Tomcat died !!! */ +CloseHandle(hServerStopEvent); +CloseHandle(hTomcat); +exit(0); // exit ungracefully so + // Service Control Manager + // will attempt a restart. break; default: /*
RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash
As of Win2000 (not sure if this existed in WinNT) you can configure a service to attempt to recover if it dies. This is fairly flexible in that you can cause it to attempt up to three restarts (after a delay period), execute a file on failure, reboot the system, etc. We might as well use the facilities the OS provides instead of duplicating this inside the service. Marc Saegesser -Original Message- From: Schreibman, David [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 6:06 PM To: '[EMAIL PROTECTED]' Subject: RE: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash If you really want the service code to be aggressive about restarting Tomcat, I would suggest just calling start_tomcat() again. This would avoid any dependency on the Service Control Manager's reaction to ungraceful exits. In fact, I've never seen any documentation from Microsoft about such restarts. The only automatic service startups that I know about are upon booting. Can you send a reference to MS documentation about this? In addition, I don't think you would want this to just keep restarting indefinitely. If the vm is crashing a lot then there's something going on that needs to be looked at. Such restart functionality should be limited to a certain number of retries. Continuing to run the vm might interfere with other software running on the same machine. Especially if the vm is crashing due to some unusual resource consumption. Just my 2 bits worth. -David -Original Message- From: Dave Ringoen [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 2:55 PM To: '[EMAIL PROTECTED]' Cc: Chien-Ming Huang; Brian Enright; Rob Webb; Patti Vrobel; Steven Velez Subject: PATCH: jk_nt_service can't automatically be restarted by Windows Service Control Manager upon crash We're using Tomcat at our company with considerable success, but discovered that if java.exe crashes for some reason, the Tomcat service won't restart automatically. I diagnosed the problem and came up with this discovery and a proposed fix. jk_nt_service.exe exits too gracefully if the java.exe process dies, notifying the Service Control Manager that it is shutting down. When Service Control Manager receives the shutdown message, it does not restart the service. It assumes that the service was supposed to be shut down. This patch makes jk_nt_service exit more abruptly without notifying SCM. With this patch, SCM will correctly initiate a restart of the Tomcat service. I couldn't file this in Bugzilla because Bugzilla was down. Thanks for your consideration on this patch. I'm very impressed with the Tomcat development approach and process. Dave Ringoen Alventive, Inc. cvs diff -u jk_nt_service.c (in directory C:\Temp\tomcatsrcnightly\jakarta-tomcat\src\native\mod_jk\nt_service) Index: jk_nt_service.c === RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_ service.c, v retrieving revision 1.3 diff -u -r1.3 jk_nt_service.c --- jk_nt_service.c 2001/04/24 08:49:46 1.3 +++ jk_nt_service.c 2001/08/30 18:05:02 @@ -535,6 +535,11 @@ /* * Tomcat died !!! */ +CloseHandle(hServerStopEvent); +CloseHandle(hTomcat); +exit(0); // exit ungracefully so + // Service Control Manager + // will attempt a restart. break; default: /*
RE: Tomcat 3.2.3 and getPathInfo
Using Apache 1.3.19 here's what I see. Apache does normalize the URL but there is a small difference between what it does and what Tomcat does. Apache does not remove multiple adjacent / characters. For example, http://server/cgi-bin/script/fu/bar -- PATH_INFO = /fu/bar http://server/cgi-bin/script/fu/../bar -- PATH_INFO = /bar http://server/cgi-bin/script/fu//bar -- PATH_INFO = /fu//bar The multiple adjacent / characters don't seem to have any effect on locating resources. For example, http://server///cgi-bin/script/fu/bar works just fine. Unless other comitters feel otherwise, I'll work on changes to the tomcat_32 branch to make path info work as it does with CGI in Apache. Another difference is that the REQUEST_URI CGI variable is the original non-normalized URI, but Tomcat's getRequestURI() now returns the normalized version. I'm still waiting to hear back from the servlet expert group about whether the normalization plans are going into the specification. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 12:25 AM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo So what does the Apache Web Server do for PATH_INFO on a request to http://foo.com/cgi-bin/somecgi/http://extra.com? -jh-
RE: Tomcat 3.2.3 and getPathInfo
Comments in line. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 11:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.3 and getPathInfo Marc Saegesser wrote: I just tried this using the SnoopServlet that ships with Tomcat using a URL like http://localhost:8080/servlet/SnoopServlet/http://fubar and got /http:/fubar as the path info. Your description makes it look like your losing http: in addition to the one of the /s. Is this what your seeing? Using SnoopServlet I see /http:/fubar just like you. My seeing the http: being eaten was due to how the GoTo servlet responded to the illegal URL being used. So that's good, it's only the double-slash to single-slash issue. It's a hard issue, but a straightforward issue. I'm glad we're seeing the same thing. The issue can certainly be solved, after all, its only code. :-) This problem is almost certainly caused the URL normalization code that got put into 3.2.3 to fix a serious security hole. This is going to be difficult to resolve. We have to normalize the URL before the servlet container uses it (I think this is even going to be added to the latest servlet specification) or some really bad things can happen with prefix mapping. However, until we've done the prefix mapping we can't know what part of the URL refers to a servlet and what part is path info. Getting back the original non-normalized path info is going to be tricky. I don't recall any EG discussion about normalizing the URL before the container sees it. Generally the spec makes contracts on the container as it interfaces with the servlet and doesn't make any statements about a web server might support a plug-in. This happened recently, Craig would probably have more details. The specification does discuss the mapping of URLs into servlets and this is where the problem lies. For example a URL like http://localhost:8080/examples/sercurity/../security/protected/index.jsp obviously refers to a resource inside an area protected by a security-constraint but it doesn't match the prefix url-pattern of /jsp/security/protected unless the URL is first normalized. The solution proposed was to normalize the URL as it entered the container. The value returned by getRequestURI() and any other method that returns the URI would *always* return the normalized URI. This solves the security constraint problems, but it seems it causes problems with path info. There two choices here. We either don't normalize the path info or we don't. I think you can make a case for both sides but I'd lean towards keeping it normalized. This is even worse because we also won't allow the URL to be encoded like http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar because we make some rather draconian precautions to ensure that nastily encoded URLs can't obtain access to protected resources (or even resources outside the webapp). Hmm... I wonder if Tomcat has the right to make illegal what HTTP would allow? As I recall, our constraints were basically lifted from the Apache HTTP server. Our rationale was that it was far better to preclude some odd URLs than to leave open the possibility that files outside the web application could be accessed via the container. This was a *really* bad security hole. I'll have to give this one some thought. If URL normalization is being added to the specification then there should also some guidance on how it relates to path info. As I understand it, extra path info has to be returned in its simple decoded form. -jh-
RE: Tomcat 3.2.3 and getPathInfo
I just tried this using the SnoopServlet that ships with Tomcat using a URL like http://localhost:8080/servlet/SnoopServlet/http://fubar and got /http:/fubar as the path info. Your description makes it look like your losing http: in addition to the one of the /s. Is this what your seeing? This problem is almost certainly caused the URL normalization code that got put into 3.2.3 to fix a serious security hole. This is going to be difficult to resolve. We have to normalize the URL before the servlet container uses it (I think this is even going to be added to the latest servlet specification) or some really bad things can happen with prefix mapping. However, until we've done the prefix mapping we can't know what part of the URL refers to a servlet and what part is path info. Getting back the original non-normalized path info is going to be tricky. This is even worse because we also won't allow the URL to be encoded like http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar because we make some rather draconian precautions to ensure that nastily encoded URLs can't obtain access to protected resources (or even resources outside the webapp). I'll have to give this one some thought. If URL normalization is being added to the specification then there should also some guidance on how it relates to path info. I'll CC this to servletapi-feedback. Marc Saegesser -Original Message- From: Jason Hunter [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 5:00 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.3 and getPathInfo It seems that Tomcat 3.2.3 has a bug (a regression) that hits my book's Example 5-5. See: http://www.servlets.com/jservlet2/examples/ch05/index.html#ex05_05 The bug is that for the following URL: http://www.servlets.com/jservlet2/examples/ch05/goto/http://www.se rvlets.com the goto servlet should have extra path info of http://www.servlets.com; and in fact does with Tomcat 3.2.1 but with 3.2.3 it now returns /www.servlets.com. My guess is the server may be trying to do a windows to unix filename conversion? It could also be a side effect of decoding, although there are no special chars there to be decoded. Is this a known issue? I didn't find anything with a quick list scan. -jh-
RE: imap close_wait with Tomcat 3.2.1
A socket enters the CLOSE_WAIT state when it receives a FIN packet from the other side. It remains in this state until the application issues a close() on the socket. At that point a FIN packet is sent and the socket enters the LAST_ACK state until the associated ACK packet is received. The Stevens _TCP/IP Illustrated, Volume 1_ book is almost required reading for anyone doing TCP/IP programming. I don't think this is a Tomcat problem, but most likely something in your servlet code that isn't properly closing down the connections to the IMAP server (or more probably, not handling the situation where the IMAP server closes its end of the connection). Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 1:05 PM To: [EMAIL PROTECTED] Subject: imap close_wait with Tomcat 3.2.1 I am running a production server with Apache 1.3.14 and Tomcat 3.2.1. I have developed a JSP-JavaBeans-Based WebMail that runs on this RH Linux 7.1 server. While debuging I noticed that if I logout of the webmail (click logout) I see the connection to the imap server being closed. But somehow, after several users accessing the site, I notice, using netstat -a imap, there is a growning number of close_wait sockets. Eventually I get a connection failure exception if I try to login. That is because there are no more sockets available to the server. I read here and there that for some reason Tomcat is not releasing those sockets. Does it have to do with the possibility that some users just close the browser instead of pressing logout? When I stop and start Tomcat I notice that all the close_wait sockets are released. Which makes me feel it is a problem with my code/Tomcat's. By any means how can I fix this problem. It is getting irritating to repeatedly stop and start tomcat whenever I get that exception. With the site load growing I am affraid that the server will crash every 5 minutes. Now I have to restart every other day. Thanks in advance. Lumi __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
RE: imap close_wait with Tomcat 3.2.1
I've never dealt with the JavaMail API so I can't really give you any details. I'm sure there are more appropriate forums for discussing those issues. The sockets are going away when you stop Tomcat for one of two reasons. First, there's code in your servlets' destroy() method that is actively closing the connections or the VM is forcefully closing them as it shuts down. I would guess (and this really is a guess because I've never used JavaMail or IMAP) that the IMAP server is shutting down the connection from its side, say for inactivity, and you're still holding on to a reference to some object on your side that's holding open the client half of the socket. At any rate, this isn't a topic that's relevant to tomcat-dev. Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 1:52 PM To: [EMAIL PROTECTED] Subject: RE: imap close_wait with Tomcat 3.2.1 Hi, Thank you Marc for your reply. As a matter of fact I am using JavaMail API to handle my communication to the IMAP server. So all the lower level sockets, etc., are transparent to me. Is there a way I can look at this? And why do I see the sockets being released once I shutdonw Tomcat? Thanks. Lumi. --- Marc Saegesser [EMAIL PROTECTED] wrote: A socket enters the CLOSE_WAIT state when it receives a FIN packet from the other side. It remains in this state until the application issues a close() on the socket. At that point a FIN packet is sent and the socket enters the LAST_ACK state until the associated ACK packet is received. The Stevens _TCP/IP Illustrated, Volume 1_ book is almost required reading for anyone doing TCP/IP programming. I don't think this is a Tomcat problem, but most likely something in your servlet code that isn't properly closing down the connections to the IMAP server (or more probably, not handling the situation where the IMAP server closes its end of the connection). Marc Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 1:05 PM To: [EMAIL PROTECTED] Subject: imap close_wait with Tomcat 3.2.1 I am running a production server with Apache 1.3.14 and Tomcat 3.2.1. I have developed a JSP-JavaBeans-Based WebMail that runs on this RH Linux 7.1 server. While debuging I noticed that if I logout of the webmail (click logout) I see the connection to the imap server being closed. But somehow, after several users accessing the site, I notice, using netstat -a imap, there is a growning number of close_wait sockets. Eventually I get a connection failure exception if I try to login. That is because there are no more sockets available to the server. I read here and there that for some reason Tomcat is not releasing those sockets. Does it have to do with the possibility that some users just close the browser instead of pressing logout? When I stop and start Tomcat I notice that all the close_wait sockets are released. Which makes me feel it is a problem with my code/Tomcat's. By any means how can I fix this problem. It is getting irritating to repeatedly stop and start tomcat whenever I get that exception. With the site load growing I am affraid that the server will crash every 5 minutes. Now I have to restart every other day. Thanks in advance. Lumi __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
RE: [PATCH] TC 3.2.3 Bug #1141
I committed the patch. Bugzilla 1141 isn't a Tomcat bug, could you please verify the bug number so I can mark is closed? Marc Saegesser -Original Message- From: Jeff Kilbride [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 4:13 PM To: [EMAIL PROTECTED] Subject: [PATCH] TC 3.2.3 Bug #1141 I've wrapped the cookie creation in a try/catch to avoid having the Exception kill the request. I also added some logging in the catch to log the original cookie header string. Maybe I'll be able to find out what's going on... This is patched against the 3.2.3 final source. Thanks, --jeff
RE: I would like to know what tomcat release bug 345 was deferred to, still doesn't seem to be fixed on tomcat 3.2.3
Basically, there just wasn't time in the 3.2.2 release schedule to get this one fixed. Tomcat 3.2.3 was released earlier than planned due to a security problem and this bug hadn't been addressed yet. If someone would like to post a patch I will review and commit it. Marc Saegesser -Original Message- From: Stephen Dittmer [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 26, 2001 10:34 AM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Cc: Henry Yeh; Irene Pan; Jack Egan; Wayne Tang Subject: I would like to know what tomcat release bug 345 was deferred to, still doesn't seem to be fixed on tomcat 3.2.3 I would like to know the status of this bug and what release it is going to be addressed in ? I found another person had filed bug 345 quite awhile back. We need the proper date header response back to browser so it won't reload staic files all the time. We don't want to use the IIS redirect as a way around this. This issue did not seem to get fixed/addressed in tomcat 3.2.3 which we just tried out. Here is a description of bug #345. Their is no date header in the Tomcat generated response, this is critical in case Tomcat is not running behind Apache e.g. According to the HTTP specs (RFC 2616) the Date header MUST be included by the origin server. --- Additional Comments From Marc Saegesser mailto:[EMAIL PROTECTED] 2001-03-21 11:46 --- This won't be addressed for Tomcat 3.2.2 but will be evaluated for a later release.
RE: [PROPOSAL] Tomcat 4.0-beta-6 Release on Thursday 07/19/2001
Please vote on a Tomcat 4.0-beta-6 Release: [ ] +1 - I support this proposal, and will actively assist [X] +0 - I support this proposal, but do not have time to assist [ ] -0 - I do not support this proposal, but am not going to resist :-) [ ] -1 - I oppose this proposal (backed by reasons and/or workarounds) Marc Saegesser
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
remm01/07/16 18:04:29
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
Log:
- %25, %2F, %2E and %5C are now forbidden in the request URI. I
hope this
is not a problem with multi-byte characters.
- Medium risk fix : always finish the response. That could lead
to connection
management problems. That has to be changed since otherwise
no HTTP error
report would be generated when something bad happened when parsing
the request.
snip
+// Prevent encoding '%', '/', '.' and '\', which are
special reserved
+// characters
+if ((normalized.indexOf(%25) 0) ||
(normalized.indexOf(%2F) 0)
+|| (normalized.indexOf(%2E) 0)
+|| (normalized.indexOf(%5C) 0)) {
+return null;
+}
This code will do a case sensitive comparison. So, for example, %2E will be
forbidden, but %2e will be allowed. Escapes are not case sensitive.
RE: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
remm01/07/16 18:04:29
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
Log:
- %25, %2F, %2E and %5C are now forbidden in the request URI. I
hope this
is not a problem with multi-byte characters.
- Medium risk fix : always finish the response. That could lead
to connection
management problems. That has to be changed since otherwise
no HTTP error
report would be generated when something bad happened when parsing
the request.
snip
+// Prevent encoding '%', '/', '.' and '\', which are
special reserved
+// characters
+if ((normalized.indexOf(%25) 0) ||
(normalized.indexOf(%2F) 0)
+|| (normalized.indexOf(%2E) 0)
+|| (normalized.indexOf(%5C) 0)) {
+return null;
+}
I think these comparisons should be = instead of .
RE: Tomcat 3.2.2 and Error page 404
This has already been fixed in 3.2.3-dev. Try the latest nightly build. -Original Message- From: David Rees [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 04, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.2 and Error page 404 On Wed, Jul 04, 2001 at 11:53:05AM -0700, Renato Weiner wrote: Hi all, I know this has been discussed, but I can't find an ultimate answer on this topic. I'm running Tomcat 3.2.2, I have latest the StaticInterceptor.java from CVS. If I configure my web.xml with a dynamic 404 error ( let's sat 404.jsp ) that doesn't exist, I got an endless loop: 2001-07-04 02:10:17 - Ctx( : ): 404 R( + /servlet/xxx + null) JSP file not found 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 2001-07-04 02:10:17 - Ctx( : ): Get real path /404.jsp /home/client1/404.jsp /home/client1 Do anybody has a solution for this ? I have hit this myself. The only solution is to make sure that the error pages you define in face do exist. I haven't had time to look into root cause of this myself, but I'm not familiar with the Tomcat source anyway... -Dave
RE: Problem with URLPatternMatcher
Tomcat 3.2 uses org.apache.tomcat.util.PrefixMapper for mapping URLs into
mapping URL patterns into servlets. The
org.apache.tomcat.request.AccessInterceptor class handles the security
constraint mappings internally.
-Original Message-
From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 4:55 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Problem with URLPatternMatcher
Well, I was but noticed it had this problem. I did fix the code,
however I
am not sure whether or not I am going to use it. I do need a URLMatcher.
If you have any suggestions as to a fast one that would be great. What is
tomcat using to do its security path constraint matching now.
Creighton
-Original Message-
From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 5:47 PM
To: [EMAIL PROTECTED]
Subject: RE: Problem with URLPatternMatcher
Yep, it looks like this code is broken, but it isn't actually
used anywhere
within Tomcat. In fact it has been removed in 3.3. Are you trying ot use
this class directly in your code?
-Original Message-
From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 8:57 AM
To: '[EMAIL PROTECTED]'
Subject: Problem with URLPatternMatcher
I have noticed that there is a problem in URLPatternMatcher. It
seems that
in the match function we do not update the length. This is a
problem because
it causes the pattern matcher not to return the longest pattern.
I noticed
this some time ago but thought it was fixed in latter releases
but it turns
out it is still a problem in 3.2.2. I have included the source
with the fix
in this email.
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.util.pattern;
import java.util.Enumeration;
/**
* A form of pattern matching for URLs in which the object corresponding
* to the longest matching pattern is returned.
*
* @author Harish Prabandham
*/
public class URLPatternMatcher implements PatternMatcher {
private ImplicationTable itable = new ImplicationTable();
public URLPatternMatcher() {
}
public void set(String pattern, Object value) {
itable.put(new WildcardPattern(pattern), value);
}
public void remove(String pattern) {
itable.remove(pattern);
}
public Object match(String key) {
// Since we want the longest pattern match, we cannot use the
// itable.get(key)...
int len =0;
Object val = null;
for(Enumeration e = itable.keys(key); e.hasMoreElements(); ){
Object thiskey = e.nextElement();
String pattern = thiskey.toString();
if(pattern.length() len){
val = itable.getValue(thiskey);
/*
*Update 6-25-001
*/
len=pattern.length();
}
}
return val;
}
public static void main(String[] args) {
PatternMatcher p = new URLPatternMatcher();
try {
p.set(*, default);
p.set(args[0], works);
System.out.println(Match: + p.match(args[1]));
}catch(Exception e) {
e.printStackTrace();
}
}
}
Creighton Kirkendall
Senior Software Engineer
Hobsons
[EMAIL PROTECTED]
-Original Message-
From: kevin seguin [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 9:36 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Intercepto
r.java
[EMAIL PROTECTED] wrote:
On Sun, 24 Jun 2001, kevin seguin wrote:
i've been thinking about this, and, well, isn't this
BaseRequest you're
talking about kind of what org.apache.coyote.Request is?
does it make
sense to have two of these kinds of objects hanging around? is
o.a.c.Request roughly equivalent to core.Request in tomcat 3??
Certainly not for the second part - the core.Request in tomcat3
has a lot
of tomcat3-specific code ( Container, ContextManager, calls
to hooks to
get special info like encoding, etc ).
The BaseRequest ( or o.a.c.Request ) is focused on the
basic information associated with a request, as received by
the protocol
adapter.
For the first part - that's true, AjpRequest is very similar in
goal with
o.a.c.Request ( thanks to the refactoring you did :-).
As I said, I like o.a.coyote, but right now my goal is to see Ajp14
working, and using the existing (working) AjpRequest is easier. Also,
coyote has more than the base request - I would let this settle down.
i hear that :) my immediate goal is ajp13 for tomcat 4 :) i've checked
RE: Plz help! Tomcat blocks when calling itself - i am desperate!
Do really need to use SingleThreadedModel for your servlets? In general its best avoid this if at all possible. Section 3.2 of the specification only requires that a servlet container must guarantee that only one thread is executing through a specific servlet instance an any time. Containers *can* create multiple instances to handle multiple simultaneous requests, but they aren't *required* to do this. Thus this can cause portabilty problems across various containers. I'll take a look at the SingleThreadedModel code in Tomcat 3.2.2 and see fi anything jumps out at me. Your example code will help a lot. Thanks. -Original Message- From: Bari, Naeem [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:51 PM To: 'Marc Saegesser'; [EMAIL PROTECTED] Subject: RE: Plz help! Tomcat blocks when calling itself - i am desperate! Marc, Thanks for your response. I will put together a little servlet that demonstrates this. I did find out the *cause* of the problem. I think this is a bug in tomcat... The situation is this: If you have a servlet that implements the SingleThreadedModel AND this servlet opens a URL back to a servlet in the same container THEN tomcat will block/deadlock This did not happen with JServ or any other servlet container. I commented out the impements sigleThreadedModel line and it worked like a charm. Hope this helps in determining the problem. I will send the servlet to you by tomorrow. Thanks, naeem -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:24 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Plz help! Tomcat blocks when calling itself - i am desperate! Any chance you could send a small sample application that demonstrates the problem? -Original Message- From: Bari, Naeem [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 2:23 PM To: '[EMAIL PROTECTED]' Subject: Plz help! Tomcat blocks when calling itself - i am desperate! I apologize for posting in the dev group, but postings to the user group have not shed any light on my problem, and I getting desperate! Here is my problem: -- My environment: Solaris 8 (fully patched) jdk 1.3.1, with hotspot enabled tomcat 3.2.2 apache 1.3.19 The problem: I have a servlet that opens a URL connection to the servlet container. So if I call http://blah/blinky, where blinky is my servlet, it is possible under some situations for this servlet to open a URL such as http://blah/lumpy, where lumpy is some other servlet. This is part of a largish site publishing framework I built on top of JServ. Now, things worked great with JServ, but I am having a devil of a time getting this to work in Tomcat. Observations: When the blinky servlet opens a URL to the same tomcat instance, the log entries for mod_jk go as far as making the call to marshal stuff before calling tomcat - as seen by the mod_jk.log entry: [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done At this point, nothing happens. I *should* be seeing entries for the jk_open_socket function, but they never appear. What I have tried: - I have disabled the default 8080 listener, thinking it may be interfering. No luck - I changed the cachesize of the ajp12 and ajp13 workers to 8 from the default of 1. No luck - I added the min_spare_threads parameter to the entries for the ajp12 and ajp13 connectors in server.xml No luck - switched between tomcat 3.2.1 and 3.2.2 *and* 4.0b5 No luck - upgraded apache to 1.3.19 No luck - switched between jdk1.2.2 and jdk1.3.1 No Luck - switched between solaris and win2k No luck - Torn my hair out from the roots No luck I am at my wits end. Any help will be gratefully accepted. TIA, naeem
RE: Plz help! Tomcat blocks when calling itself - i am desperate!
Any chance you could send a small sample application that demonstrates the problem? -Original Message- From: Bari, Naeem [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 2:23 PM To: '[EMAIL PROTECTED]' Subject: Plz help! Tomcat blocks when calling itself - i am desperate! I apologize for posting in the dev group, but postings to the user group have not shed any light on my problem, and I getting desperate! Here is my problem: -- My environment: Solaris 8 (fully patched) jdk 1.3.1, with hotspot enabled tomcat 3.2.2 apache 1.3.19 The problem: I have a servlet that opens a URL connection to the servlet container. So if I call http://blah/blinky, where blinky is my servlet, it is possible under some situations for this servlet to open a URL such as http://blah/lumpy, where lumpy is some other servlet. This is part of a largish site publishing framework I built on top of JServ. Now, things worked great with JServ, but I am having a devil of a time getting this to work in Tomcat. Observations: When the blinky servlet opens a URL to the same tomcat instance, the log entries for mod_jk go as far as making the call to marshal stuff before calling tomcat - as seen by the mod_jk.log entry: [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done At this point, nothing happens. I *should* be seeing entries for the jk_open_socket function, but they never appear. What I have tried: - I have disabled the default 8080 listener, thinking it may be interfering. No luck - I changed the cachesize of the ajp12 and ajp13 workers to 8 from the default of 1. No luck - I added the min_spare_threads parameter to the entries for the ajp12 and ajp13 connectors in server.xml No luck - switched between tomcat 3.2.1 and 3.2.2 *and* 4.0b5 No luck - upgraded apache to 1.3.19 No luck - switched between jdk1.2.2 and jdk1.3.1 No Luck - switched between solaris and win2k No luck - Torn my hair out from the roots No luck I am at my wits end. Any help will be gratefully accepted. TIA, naeem
RE: Problem with URLPatternMatcher
Yep, it looks like this code is broken, but it isn't actually used anywhere
within Tomcat. In fact it has been removed in 3.3. Are you trying ot use
this class directly in your code?
-Original Message-
From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 8:57 AM
To: '[EMAIL PROTECTED]'
Subject: Problem with URLPatternMatcher
I have noticed that there is a problem in URLPatternMatcher. It
seems that
in the match function we do not update the length. This is a
problem because
it causes the pattern matcher not to return the longest pattern.
I noticed
this some time ago but thought it was fixed in latter releases
but it turns
out it is still a problem in 3.2.2. I have included the source
with the fix
in this email.
* http://www.apache.org/.
*
* [Additional notices, if required by prior licensing conditions]
*
*/
package org.apache.tomcat.util.pattern;
import java.util.Enumeration;
/**
* A form of pattern matching for URLs in which the object corresponding
* to the longest matching pattern is returned.
*
* @author Harish Prabandham
*/
public class URLPatternMatcher implements PatternMatcher {
private ImplicationTable itable = new ImplicationTable();
public URLPatternMatcher() {
}
public void set(String pattern, Object value) {
itable.put(new WildcardPattern(pattern), value);
}
public void remove(String pattern) {
itable.remove(pattern);
}
public Object match(String key) {
// Since we want the longest pattern match, we cannot use the
// itable.get(key)...
int len =0;
Object val = null;
for(Enumeration e = itable.keys(key); e.hasMoreElements(); ){
Object thiskey = e.nextElement();
String pattern = thiskey.toString();
if(pattern.length() len){
val = itable.getValue(thiskey);
/*
*Update 6-25-001
*/
len=pattern.length();
}
}
return val;
}
public static void main(String[] args) {
PatternMatcher p = new URLPatternMatcher();
try {
p.set(*, default);
p.set(args[0], works);
System.out.println(Match: + p.match(args[1]));
}catch(Exception e) {
e.printStackTrace();
}
}
}
Creighton Kirkendall
Senior Software Engineer
Hobsons
[EMAIL PROTECTED]
-Original Message-
From: kevin seguin [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 9:36 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Intercepto
r.java
[EMAIL PROTECTED] wrote:
On Sun, 24 Jun 2001, kevin seguin wrote:
i've been thinking about this, and, well, isn't this
BaseRequest you're
talking about kind of what org.apache.coyote.Request is? does it make
sense to have two of these kinds of objects hanging around? is
o.a.c.Request roughly equivalent to core.Request in tomcat 3??
Certainly not for the second part - the core.Request in tomcat3
has a lot
of tomcat3-specific code ( Container, ContextManager, calls to hooks to
get special info like encoding, etc ).
The BaseRequest ( or o.a.c.Request ) is focused on the
basic information associated with a request, as received by
the protocol
adapter.
For the first part - that's true, AjpRequest is very similar in
goal with
o.a.c.Request ( thanks to the refactoring you did :-).
As I said, I like o.a.coyote, but right now my goal is to see Ajp14
working, and using the existing (working) AjpRequest is easier. Also,
coyote has more than the base request - I would let this settle down.
i hear that :) my immediate goal is ajp13 for tomcat 4 :) i've checked
in an intial version of BaseRequest. it may need some further work...
-kevin.
RE: Anyone know why the ISAPI redirector works how it does?
I don't have any problem with the experiment, and couldn't stop the *experiment* even if I wanted to. By all means, scratch the itch. I am curious though, what it takes to cause the thread starvation in a normal environment (what ever that is). Adding the complexity of a thread pool will slow down processing by some amount in the non-starved case. For the case where thread starvation is occurring, it stands to reason that we have *lots* of requests and lots more requests and threads than processors to throwing more threads probably won't improve the throughput for Tomcat requests. It might improve the throughput for the static pages served by IIS directly since those requests won't be stuck behind potentially long running servlet requests, but then only if those long running threads are blocked on I/O. Basically, throwing threads at a problem usually doesn't do much for performance. Still, I'd be interested to see how this experiment effects performance. Marc Saegesser -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 7:11 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give it a try. Before I do, does anyone have any empirical evidence about what works best with IIS? [1] http://msdn.microsoft.com/library/default.asp? \ url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp Ignacio J. Ortega wrote: So, +1 for trying a different approach without breaking what's already there? My swahili is at times hard to understand :)) Yes i'm +1 on trying what you are proposing in another place on jtc tree and leaving iis as it is now.. I'm really courious about what you find .. every bit of performance is welcomed ever .. so if there is a bit waiting for tomcat lets catch it ..:)) i recall that i'd found the same architecture in other ISAPI modules like resin... Saludos , Ignacio J. Ortega -- Andy Armstrong, Tagish -- Andy Armstrong, Tagish
RE: Anyone know why the ISAPI redirector works how it does?
Again, threads don't improve performance, in fact they degrade performance and on some platforms (namely, Windows) they can degrade performance very quickly. Context switching between threads on Win32 is *really, really* expensive (several hundred instructions in kernel space). Without processors to back up the threads you can just end up wasting cycles switching between threads and not accomplishing real work. -Original Message- From: Andy Armstrong [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 9:18 AM To: [EMAIL PROTECTED] Subject: Re: Anyone know why the ISAPI redirector works how it does? (sorry to follow myself up, but I've just found some more evidence about this) Andy Armstrong wrote: [snip] Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. Hmm. Well, surprisingly, according to this page[1] the default thread pool size for IIS is 10 times the number of processors and the server doesn't do anything adaptive with this number though it can be changed in the registry. This number does seem surprisingly low -- I can see how, in cases where the server was handling a lot of traffic of which some was being delegated to Tomcat there could be starvation. [1] http://www.google.com/search?q=cache:2jnr72XWvVU: \ msdn.microsoft.com/componentresources/html/articles \ /ta/ta_030.asp+iis+thread+pool+sizehl=en -- Andy Armstrong, Tagish
Historical question about BufferedServletOutputStream.java
Ever since version 1.1, BufferedServletOutputStream.flush() checks to see if if the response is using an PrintWriter and if it is it ignores the flush request. The question is why? My guess is that it had something to do with the fact that the PrintWriter itself has a buffer because it uses an OutputStreamWriter internally, but that still doesn't make any sense. The net result is that if a servlet author calls flush on the PrintWriter returned from response.getWriter() nothing *appears* to happen. Internally what happens is that the bytes from the PrintWriter's OutputStreamWriter are flushed into the BufferedServletOutputStream's buffer, but they aren't sent to the client. This is not the behaviour that most servlet authors would expect and I don't see any reason in the spec that would mandate it. Does anyone remember or know why BufferedServletOutputStream.flush() does nothing when a PrintWriter is in use? There's bug posted against this behaviour and I don't see any reason why the buffer shouldn't be sent to the client when a PrintWriter is in use, but before I make a change to something that's been around for so long I thought I'd see if anyone remembers why it was done this way to start with.
RE: Tomcat standalone JVM running single servlet overruns heap
I've had very good luck in the past using JProbe to track down memory problems. -Original Message- From: Tom Amiro [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 20, 2001 4:27 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Tomcat standalone JVM running single servlet overruns heap Hello, I tried to send this message before but it got bounced -- probably the attachments. I've deployed a Java servlet that gets about 300-400 hits a day. Tomcat (standalone mode) keeps running out of memory and crashing. The servlet does an XSLTC transformation on an XML file about 1.5MB large, sending html to 'out'. Tomcat is dedicated to just this little servlet and some JSP data entry tools used to maintain the XML file. I've found that even when we refrain from using the data entry tools, and just let the servlet run, the problem still happens. At first, I thought I must be doing something wrong. So I did every thing I could to plug memory leaks in my code to free up resources once they are no longer referenced. I've closed all streams and set the transformation objects (dom, parser, translet) to null immediately after the transformation is done. I've collected data and can send you a graph. Today it showed the heapsize -- (rt.totalMemory()-rt.freeMemory() -- stayed around 5-6MB for 178 hits on the servlet. Then it quickly went up. From 190 to 280 hits it averaged 40MB. Then at about 300 hits it went over 120MB and the servlet starting giving Out-of-Memory errors soon thereafter. In the very beginning, I sent mail to the users group and have implemented suggestions, like increasing the file descriptors to 1024, minimizing sessions (session.setMaxInactiveInterval(120), starting the Tomcat JVM with more memory (-Xmx160m). That has helped somewhat. It takes longer to crash, but it hasn't stayed up more than 24 hours. Here's the configuration: - Solaris 2.7 on an Ultra-2 with all the patches. - one processor with 512MB memory - Java 1.3 is installed (must have VMPI cause hprof works) - Tomcat 3.2.2 jars - Session timeout 120 seconds - Using the thread pool with max_threads 25 max_spare_threads 10 min_spare_threads 5 I've been trying for almost a month to get past this memory problem. Something is wrong. If it is just operator error, then what could be my mistake. It is looking like a bug in Tomcat or the Java SDK. If it were a simple memory leak in my application code, then I'd think the heap size would go up progressively, since the servlet is doing the same thing over and over. The only difference betwee one hit from another is the parameters passed from the user that are feed to the XSLTC translet. I'm in software QA in the XTC center at Sun. In fact, I've been doing XSLT conformance testing on Sun's (now Apache XalanJ2's XSLTC) processor. I don't think the problem is in XSLTC but I'd be happy to be proved wrong. I'm not on tomcat-dev, so please copy [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks, Tom
RE: 3.2.1 vs 3.2.2 versions - Oren
Tomcat 3.2.2 is a bug fix release. The release notes in src/doc/readme detail the changes between 3.2.1 and 3.2.2. -Original Message- From: Oren Deri, Nice-Eye [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 3:54 AM To: [EMAIL PROTECTED] Subject: 3.2.1 vs 3.2.2 versions - Oren Which is better and what the differences. should I expect problem by moving from 1 to 2.s Oren Deri ___ Oren Deri (E-mail).vcf
RE: Where is jni_connect for Tomcat 3.2.2?
Its there now, but I have no way to test it at present. -Original Message- From: Engel Sanchez [mailto:[EMAIL PROTECTED]] Sent: Monday, June 18, 2001 4:34 PM To: [EMAIL PROTECTED] Subject: Where is jni_connect for Tomcat 3.2.2? I just installed tomcat in win2k running IIS and got it working. I'm interested in trying it out as an in-process module, but even though the instructions mention getting jni_connect.dll from the distribution site, this file is not present for Tomcat 3.2.2 (it is there for 3.2.1). Is it no longer supported? Thanks in advance. = _ @ Engel Amin Sanchez-Santos @:O) -- Some afro is better than no afro @ E-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/
Plans for Tomcat 3.2.3 and later
Now that Tomcat 3.2.2 is out it's time to starting thinking about 3.2.3. My thoughts are to have a release for 3.2.3 in three or four months. This will be strictly a bug fix release. The only hard and fast release requirements are to fix any specification compliance issues that may be discovered in 3.2.2 and that are no regression failures. Beyond that, any bugs are fair game and 3.2.3 will roll these up into a public release. I'll volunteer to be the release manager for this release (unless someone else is crazy enough to want the job). Any discussion? Comments? I'll put together a formal release plan in the next couple days. Marc Saegesser
RE: Source script reveal bug
All known URL Trickery source exposure bugs have been fixed in Tomcat 3.2.2 (and 3.3 and 4.0). -Original Message- From: Venkat [mailto:[EMAIL PROTECTED]] Sent: Friday, June 08, 2001 4:14 AM To: [EMAIL PROTECTED] Subject: Source script reveal bug I should do this today, please advise # Hi All Since I could not get a solution from the archives, this posting is inevitable I'm using Tomcat 3.2.1 on my production server on Win2K with IIS 5. I recently come across about a bug in this version of Tomcat which reveals JSP script source code by URL trickery. I hope many of you guys there are aware of it and fixed it too. I wish to know that is it a bug in Windows platform (because coldfusion on windows has similar problem add +.htr to your cfm url reveals cfm source code, and MS has a fix for NT 4.0 and win2K) If it's a bug in Tomcat, is there a fix for it and how to do it. Please reply with complete details/urls Regards Venkat ### _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: Tomcat 3.2.2 doesn't builds with jdk 1.1.8
Tomcat 3.2.2 will run on JDK1.1 VMs, but right now it only builds on JDK1.2.
These securitiy manager classes will never be used if Tomcat is running on a
1.1 VM. Hopefully we can update the build.xml for the next release to
exclude these classes for 1.1 builds.
-Original Message-
From: Alexander Zagrebin [mailto:[EMAIL PROTECTED]]
Sent: Saturday, June 02, 2001 7:04 AM
To: [EMAIL PROTECTED]
Subject: Tomcat 3.2.2 doesn't builds with jdk 1.1.8
Hi
Tomcat 3.2.2 doesn't builds with jdk 1.1.8:
=
...
tomcat:
[javac] Compiling 215 source files to D:\work\build\tomcat\classes
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:116: Interface
org.apache.tomcat.util.compat.PrivilegedExceptionAction of nested class
org.apache.tomcat.util.compat.Jdk12Support. PrivilegedProxy not found.
[javac] static class PrivilegedProxy implements
PrivilegedExceptionAction
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\facad
e\RequestD
ispatcherImpl.java:146: Undefined variable, class, or package name: java
[javac] java.security.AccessController.doPrivileged(
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\facad
e\RequestD
ispatcherImpl.java:155: Class
org.apache.tomcat.facade.PrivilegedActionException not found in type
declaration.
[javac] } catch( PrivilegedActionException pe) {
[javac]^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\facad
e\RequestD
ispatcherImpl.java:254: Undefined variable, class, or package name: java
[javac] java.security.AccessController.doPrivileged(
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\facad
e\RequestD
ispatcherImpl.java:263: Class
org.apache.tomcat.facade.PrivilegedActionException not found in type
declaration.
[javac] } catch( PrivilegedActionException pe) {
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:77: Undefined variable or class name: URLClassLoader
[javac] return URLClassLoader.newInstance( urls, parent );
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:89: Undefined variable or class name: AccessController
[javac] return AccessController.
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:91: Class
org.apache.tomcat.util.compat.PrivilegedActionException not found in type
declaration.
[javac] } catch( PrivilegedActionException pe ) {
[javac]^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:100: Method
setContextClassLoader(java.lang.ClassLoader) not
found in class java.lang.Thread.
[javac] Thread.currentThread().setContextClassLoader(cl);
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:104: Method getContextClassLoader() not found in class
java.lang.Thread.
[javac] return Thread.currentThread().getContextClassLoader();
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:108: Class org.apache.tomcat.util.compat.URLClassLoader not
found in type declaration.
[javac] return ((URLClassLoader)cl).getURLs();
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:111: Class org.apache.tomcat.util.compat.URLClassLoader not
found in type declaration.
[javac] URLClassLoader scl=(URLClassLoader)cl;
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:111: Class org.apache.tomcat.util.compat.URLClassLoader not
found in type declaration.
[javac] URLClassLoader scl=(URLClassLoader)cl;
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:112: Class org.apache.tomcat.util.compat.URLClassLoader not
found in type declaration.
[javac] return ((URLClassLoader)cl.getParent()).getURLs();
[javac] ^
[javac]
D:\work\jakarta-tomcat-3.2.2-src\src\share\org\apache\tomcat\util\
compat\Jdk
12Support.java:112: Method getParent() not found in class
java.lang.ClassLoader.
[javac]
RE: Session ID in load balancer in 3.2.2
How about a diff -u or at least may be a file name? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mathias Herberts Sent: Monday, June 04, 2001 6:53 AM To: [EMAIL PROTECTED] Subject: Session ID in load balancer in 3.2.2 According to the RELEASE-NOTES, the load balancer was fixed to correctly extract the session ID from the Cookie. It seems the extraction from the URI has not been corrected, line 136 should read *id_end = '\0'; instead of id_end = NULL; Has this been corrected in the current CVS source tree? Mathias.
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
The fix for the first part of the problem has already been committed for 3.2.3. The other problem, what happens if your 404 error page doesn't really exist has not been addressed yet, but I'll look into it. Marc Saegesser -Original Message- From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 12:04 AM To: [EMAIL PROTECTED] Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2 Hmm.. In fact (in 3.2.2 atleast), it does not even matter if the file exists or not, since the FileHandler simply uses the originally requested file and StaticInterceptor. So I suppose its the same bug alltogether. If things are fixed in 3.2.3, I'm happy enough though. The dirty fix I posted earlier works fine for me in the mean time. A related bug to this is a nasty stack overflow error if an error page that you define is not found. It's pretty easy to reproduce, just add this to your web.xml:
Tomcat 3.2 Wins Java Editor's Choice Award!
Congratulations to all Tomcat developers! I just got back from the JavaWorld Editor's Choice Award presentation and I'm glad to announce that Jakarta Tomcat 3.2 won the award for Most Innovative Java Product. I'll update the Jakarta and Tomcat web sites once I see that the JavaWorld web site has the information posted. Again, thanks to everyone who made this possible. The entire Tomcat community won something tonight. Marc Saegesser
RE: [VOTE] New Committer: Mike Anderson
+1 Welcome aboard! -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 2:31 AM To: [EMAIL PROTECTED] Subject: [VOTE] New Committer: Mike Anderson I would like to propose Mike Anderson as a new committer. He found many subtils bugs in mod_jk and since he's working on Netware platforms, it will a great help to improve connectors on this OS. Vote please - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: 3.2.2 - handling requests for WEB-INF/*
Read the specification, section 9.4: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that arent in the document root of the application. It is important to note that the WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 8:06 AM To: [EMAIL PROTECTED] Subject: 3.2.2 - handling requests for WEB-INF/* I've taken a quick crawl through the code and want to re-suggest a possible cause for the problems we're seeing on 3.2.2 dealing with requests to the WEB-INF directory. First of all, this is really the first time I've been through the tomcat code, and I've done it quickly so there's a high chance for error. However, I've tracked the following path: ContextManager.service ContextManager.internalService ContextManager.processRequest SimpleMapper1.requestMap My assumption here is that ContextManager.service is a main entry point...it appears to be called by almost everything AND has a comment to that effect. From that point, there are not many branch points until you reach SimpleMapper1.requestMap. The first thing requestMap does is check if you're asking about the WEB-INF directory and returns 404 if you are. So, my working theorey is that anything that calls ContextManager.service, whether its loading a class from a .jar file, getting a configuration file...anything...will be vetoed by SimpleMapper1.requestMap. A fix I would suggest - change SimpleMapper1.requestMap to only veto requests to the standard tomcat files - directory browsing and web.xml. We can fine tune it later, but this appears to be a quick dirty fix. Someone more familar with the code could verify it for me: am I way in left field? Brian Flynn
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening. -Original Message- From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 12:50 AM To: [EMAIL PROTECTED] Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2 I use virtual hosts, but don't think that is the cause, although I have not traced this down (I will check that aswell). As I think of it, the webapp could simply be empty one with a web.xml like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app error-page error-code404/error-code location/errors/404.html/location /error-page /web-app Now, when I request any file through Tomcat, it will fail (error 500: Stack overflow). When a JSP is specified for location, it works fine. Tomcat outputs a correct message from the CM about the requested error page, but FileHandler outputs the originally requested path as requested file. I will set up an independent Tomcat installation and try this again without virtual hosts. If I have the time today, I will wrap up a webapp and post the .war file. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 8:54 PM Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
RE: [BUG T322] Bug in getServletContext().getResource() for relative URLs
According to the spec, the path passed to ServletContext.getResource() must start with a /. -Original Message- From: Stevenson, Chris (SSABSA) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 1:44 AM To: [EMAIL PROTECTED] Subject: [BUG T322] Bug in getServletContext().getResource() for relative URLs Bugzilla is down so I am forced to send this to the list: Relative URLs from a servlet resource do not work (Tomcat 3.2.2). I have the following code in a Servlet: URL propURL = getServletContext().getResource( /WEB-INF/connection.properties ) URL configURL = new URL( url, config.xml ); The servlet throws a FileNotFoundException on configURL.getInputStream() some diagnostic info follows: Could not load configuration file: file:persist.config.xml propURL: file:F:\tomcat\tomcat-dev\webapps\ore\WEB-INF\connection.properties configURL: persist.config.xml Apache Tomcat/4.0-b5 works perfectly, but its using jndi. Also, if I do the following: URL configURL = new URL( url, config.xml ); configURL = new URL( configURL.toString() ); it works! java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) Full Exception is java.io.FileNotFoundException: persist.config.xml (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:64) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnect ion.java:6 9) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURL Connection .java:133) at java.net.URL.openStream(URL.java:798) at ssabsa.control.Controller.init(Controller.java:52) at ssabsa.control.Controller.getInstance(Controller.java:74) at ssabsa.ore.WoreServlet.init(WoreServlet.java:47) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) at org.apache.tomcat.core.Handler.init(Handler.java:215) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296) at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(Loa dOnStartup Interceptor.java:130) at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235)
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
This was broken in 3.2.1 and unfortunately is still broken in 3.2.2 due to the commit problem I mentioned earlier. Since this isn't a regression failure and there is a work-around we'll log it as a bug and fix it in 3.2.3. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 9:38 AM To: [EMAIL PROTECTED] Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Bloody hell. This bug was fixed a couple months ago and then got whacked by a late commit to StaticInterceptor.java. I take partial responsibility because I reviewed that commit and missed the problem. I'll try to get this taken care of this evening. -Original Message- From: Peter S. Heijnen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 12:50 AM To: [EMAIL PROTECTED] Subject: Re: Problem+Fix concerning static error pages in Tomcat 3.2.2 I use virtual hosts, but don't think that is the cause, although I have not traced this down (I will check that aswell). As I think of it, the webapp could simply be empty one with a web.xml like: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app error-page error-code404/error-code location/errors/404.html/location /error-page /web-app Now, when I request any file through Tomcat, it will fail (error 500: Stack overflow). When a JSP is specified for location, it works fine. Tomcat outputs a correct message from the CM about the requested error page, but FileHandler outputs the originally requested path as requested file. I will set up an independent Tomcat installation and try this again without virtual hosts. If I have the time today, I will wrap up a webapp and post the .war file. - Original Message - From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 8:54 PM Subject: RE: Problem+Fix concerning static error pages in Tomcat 3.2.2 Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
RE: Problem+Fix concerning static error pages in Tomcat 3.2.2
Could you please supply a sample webapp that demonstrates this? Static error pages seem to work OK for me. -Original Message- From: Peer Heijnen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 29, 2001 5:52 AM To: tomcat-dev Subject: Problem+Fix concerning static error pages in Tomcat 3.2.2 I'm using Tomcat 3.2.2 (relase) and have configured static .html files as error pages. We used JSP pages before, and everything was fine... However since we're using static files, Tomcat will enter an infinite loop and eventually crash with a stack overflow (with a good change of leaving Tomcat in a defunct state). We traced down this problem and have found a way to fix it, but I'm not sure if this is correct. All this is related to the ContextManager class: 1) Both handleStatus and handleError will call 'getHandlerForPath' when an error page was configured. 2) getHandlerForPath returns a the Handler for the error page. (since we're using static files, this will be a FileHandler). So far, so good. 3) Eventually handleStatus and handleError will do a 'errorServlet.service( req, res )' to service the error. This is were things go wrong. The problem is, that 'req' passed to the 'errorServlet.service( req, res )' call is the original request, while getHandlerForPath creates a new request internally with the error's request URI. Since the handler (FileHandler) is called with the original request URI, it will try to service a file matching that request, not the static file we configured. This, in turn, will cause and error and, in our case, an infinite loop. This can lead to very strange situations. For example, if an .jsp page generates an error and the error refers to an (existing) static file, it will actually end up showing the .jsp source file contents! The quick and dirty fix we use here is to simply add 'req.setRequestURI( ctx.getPath() + errorPath);' after the 'getHandlerForPath' calls in both handleError and handleStatus methods. I'm not really sure if we are allowed to modify the request in such a way, but error attributes are also set in this request and it seems to work fine for us. But this raises another question: why construct a completely new request and response in getHandlerForPath, and then throw it away? Cheers, Peer Heijnen
[ANNOUNCEMENT] Tomcat 3.2.2 released
I am pleased to announce that the Tomcat 3.2.2 release is now available for download at http://jakarta.apache.org/builds/tomcat/release/v3.2.2 Tomcat 3.2.2 is a maintenance release that fixes several bugs from version 3.2.1 and corrects all known specification compliance issues. The release notes file in src/doc/readme covers the details of the Tomcat 3.2.2 release. Tomcat 3.2.2 is now the latest production quality Tomcat release. Users of version 3.2.1 and earlier release are encouraged to update to this release. Marc A. Saegesser
RE: broken links
The first link works OK for me. I've fixed the second. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 26, 2001 10:14 AM To: tomcat dev Subject: FW: broken links Can someone take care of those ? Pier -- Forwarded Message From: Garrey Learmonth [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 25 May 2001 20:38:49 -0700 To: [EMAIL PROTECTED] Subject: broken links http://jakarta.apache.org/tomcat/tomcat-3.2-doc/mod_jk-howto.html http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html regs., Garrey Learmonth Cisco Systems Inc. -- End of Forwarded Message
RE: Slow session creating Tomcat 3.2.1
The initialization of Tomcat's Psuedo Random Number Generator (PRNG) can take several seconds on some platforms. The PRNG is initialized when the first session is created (its used to generate the session IDs). There are some hacks you can use in 3.2.1 to avoid this, but the best solution will be to upgrade to Tomcat 3.2.2 which should be released shortly. The PRNG initialization is fast enough in this release to not be noticable. -Original Message- From: Strubinski,Waldemar W [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 24, 2001 3:46 PM To: '[EMAIL PROTECTED]' Subject: Slow session creating Tomcat 3.2.1 I've noticed that Tomcat 3.2.1 takes a long time to create a session for the first time. I think it only takes a long time the very first time it's asked to create a session (when the first person logs in after restarting Tomcat). Do you have any suggestions how to fix it or where I can find any documentation on that? Thanks, Waldemar
[RESULTS] Final release of Tomcat 3.2.2
The voting on the final release of Tomcat 3.2.2 is closed and the results are summarized below. The proposal to release the tomcat_32 branch as Tomcat 3.2.2 passes. The final release will happen as soon as I get the binary signing mechanism in place. [7] +1. I agree with the proposal and I will help support the release. [3] +0. I agree with the proposal but I will not be able to help support the release. [0] -0. I don't agree with the proposal but I won't stop the release. [0] -1. I disagree with the proposal and will explain my reasons. Marc Saegesser
RE: [PATCH] Bug fix for #1678
This was fixed in Tomcat 3.2.2 quite some time ago. Check out the tip of
the tomcat_32 branch and look at the connector code again.
-Original Message-
From: Hiro Takahashi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 1:33 AM
To: [EMAIL PROTECTED]
Subject: [PATCH] Bug fix for #1678
This is the fix for ServletInputStream.read() bug.
#1678: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1678
The change is in Ajp13ConnectorRequest.java. This one is obviously
the one which has not been tested with a binary data.
I made this patch for 3.2.1.
Index: Ajp13ConnectorRequest.java
===
RCS file:
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/Ajp13
ConnectorRequest.java,v
retrieving revision 1.1
diff -u -r1.1 Ajp13ConnectorRequest.java
--- Ajp13ConnectorRequest.java2001/05/23 22:41:09 1.1
+++ Ajp13ConnectorRequest.java2001/05/24 06:20:53
@@ -251,8 +251,12 @@
{
if(pos = blen) {
refeelReadBuffer();
+ if (pos= blen) {
+ // seems no data
+ return -1;
+ }
}
-return bodyBuff[pos++];
+return bodyBuff[pos++] 0xff;
}
public int doRead(byte[] b, int off, int len) throws IOException
@@ -261,7 +265,6 @@
for(int i = off ; i (len + off) ; i++) {
int a = doRead();
if(-1 == a) {
-System.out.println(Y);
return i-off;
}
b[i] = (byte)a;
RE: Problem in Transferring session between http and https on Netscape
The code in Tomcat 3.2.x that encodeURL() uses to add the ;JSESSIONID= string to the URL makes several tests in order to prevent encoding a session ID onto a URL that doesn't belong the the current web application. One of these tests compares the URL scheme (HTTP, HTTPS) for the current request and the URL to be encoded and does not encode the session Id if the schemes are different. I have to admit that I'm not convinced that this is correct. The specification onlys says that if the URL does not need to be encoded encodeURL() returns the original string. There certainly isn't any reason to encode a session ID into an external URL, but I think the URL scheme test is a little too much. This isn't something that can be changed for 3.2.2 because it runs too high of a risk of breaking existing applications that depend on this behavior. It could be changed for 3.2.3 (if such a release ever comes about) and I'd be interested to see how 3.3 and 4.0 handle this situation. -Original Message- From: Deepak Raina [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 6:35 AM To: [EMAIL PROTECTED] Subject: Problem in Transferring session between http and https on Netscape I had asked this problem yesterday also.Can somebody please tell me the solution??? I'm working on a website where some pages are to be kept in https and some on http.But when we transfer from https to http, session is not transferred in Netscape.It's working fine in IE.We are using tomcat. Is there anything i should do with tomcat so that it transfers the session in Netscape or i have to do something in the settings of the Netscape? regards, deepak. INTIQUA India Intelligent solutions, Quality Execution Note: The information and data contained in this message (and attachments) may be privileged and confidential and protected from disclosure to any party or parties apart from the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.
New Tomcat web site
The jakarta-tomcat-site repository has been created and populated. The Jakarta web site has been updated to point to the new stuff. The README.txt file in the root directory has basic instructions. I claim no great ability at site design or word-smithing so consider this a merely a jumping off point. If you see something you don't like please change it. All Tomcat committers have access to this repository. Enjoy. Marc Saegesser
RE: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
I added the permissions to the global list of permissions. I've attached
the most recent tomcat.policy file.
-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 21, 2001 12:49 AM
To: [EMAIL PROTECTED]
Subject: Re: JSP and SecurityManager [was RE: 3.2.2. When's it
shipping?]
Marc Saegesser wrote:
The null check is simple enough and its already been tested in 3.3
so I feel comfortable making the change without a beta. I'll commit
the change today.
Great, thanks!
Another question regarding using the security manager and JSP. If
I use the default tomcat.policy file I can't access any JSP pages
because I get an access denied expcetion getting the line.separator
property. If I add
permission java.util.PropertyPermission line.separator, read;
permission java.util.PropertyPermission file.separator, read;
to tomcat.policy the pages are served correctly. Glenn, is there
any problem adding these two lines to the default policy? Am I
missing something else?
I've tested this but it ONLY works if you add these permissions with no
codeBase. If you add them under the specified codeBase
grant codeBase file:${tomcat.home}/-
They still cause the access exception. I have even tried the following
codeBases
grant codeBase file:c:/-
grant codeBase file:h:/-
with still the same exception. Why doesn't it work??
Rgds
Antony
-Original Message-
From: Antony Bowesman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 1:50 AM
To: [EMAIL PROTECTED]
Subject: Re: 3.2.2. When's it shipping?
Marc Saegesser wrote:
I bloody hope so.
Here's the plan. Beta 5 was released on Friday, May 11. This beta
cycle is planned for one week. Unless someone reports a show
stopping bug, and so far I haven't seen one, on Friday, May 18th.
I'll call release vote on tomcat-dev. This vote lasts for one week
and every committer gets to vote. A public release vote is open for
one week. So, the best case right now is May 28th.
Not sure if this would be a showstopper however, there is a bug in
jasper/runtime/JspFactoryImpl.java which causes a
NullPointerException.
Fixed in 3.3 but not in 3.2.2
I'm relatively new to tomcat so am not sure of the bug
reporting process
but I sent report of a bug to this list a couple of days ago.
Just tested it with b5 - bug still exists.
tomcat run -security
gives nullPointerException in jasper/runtime/JspFactoryImpl.java
due to no check for pageContext == null in releasePageContext
This is fixed in 3.3
if (pc == null) return
Rgds
Antony
-Original Message-
From: Dave Oxley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 12:54 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2. When's it shipping?
What is the current state of 3.2.2 development? Is it going to
ship any time
soon?
Dave.
[EMAIL PROTECTED]
--
Antony Bowesman
Teamware Group
[EMAIL PROTECTED]
tel: +358 9 5128 2562
fax: +358 9 5128 2705
tomcat.policy
RE: JDK DateFormat bug workaround
Looks safe enough. Go ahead.
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Sunday, May 20, 2001 4:41 PM
To: [EMAIL PROTECTED]
Subject: JDK DateFormat bug workaround
There is a lingering bug in (at least) Sun's JDK
that causes SimpleDateFormat to occasionaly throw a
StringIndexOutOfBoundsException instead of a
ParseException.
http://developer.java.sun.com/developer/bugParade/bugs/4212077.html
(Requires a cookie; thanks, Sun)
Some rogue client out there is sending a malformed
HttpDate for the 'If-Modified-Since' header (don't
know which, that info was not logged) which triggers
this bug on our servers.
I propose to follow the advice in the Sun bug report
and catch this additional exception so that Tomcat
might recover gracefully:
--- RequestUtil.java2001/05/11 22:34:28 1.14.2.4
+++ RequestUtil.java2001/05/20 22:36:41
@@ -572,17 +572,20 @@
try {
date = rfc1123Format.parse(dateString);
} catch (ParseException e) { }
+ catch (StringIndexOutOfBoundsException e) { }
if( date==null)
try {
date = rfc1036Format.parse(dateString);
} catch (ParseException e) { }
+ catch (StringIndexOutOfBoundsException e) { }
if( date==null)
try {
date = asctimeFormat.parse(dateString);
} catch (ParseException pe) {
}
+ catch (StringIndexOutOfBoundsException e) { }
if(date==null) {
return -1;
Any objections to putting this in 3.2.2?
Keith
JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
The null check is simple enough and its already been tested in 3.3 so I feel comfortable making the change without a beta. I'll commit the change today. Another question regarding using the security manager and JSP. If I use the default tomcat.policy file I can't access any JSP pages because I get an access denied expcetion getting the line.separator property. If I add permission java.util.PropertyPermission line.separator, read; permission java.util.PropertyPermission file.separator, read; to tomcat.policy the pages are served correctly. Glenn, is there any problem adding these two lines to the default policy? Am I missing something else? -Original Message- From: Antony Bowesman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 1:50 AM To: [EMAIL PROTECTED] Subject: Re: 3.2.2. When's it shipping? Marc Saegesser wrote: I bloody hope so. Here's the plan. Beta 5 was released on Friday, May 11. This beta cycle is planned for one week. Unless someone reports a show stopping bug, and so far I haven't seen one, on Friday, May 18th. I'll call release vote on tomcat-dev. This vote lasts for one week and every committer gets to vote. A public release vote is open for one week. So, the best case right now is May 28th. Not sure if this would be a showstopper however, there is a bug in jasper/runtime/JspFactoryImpl.java which causes a NullPointerException. Fixed in 3.3 but not in 3.2.2 I'm relatively new to tomcat so am not sure of the bug reporting process but I sent report of a bug to this list a couple of days ago. Just tested it with b5 - bug still exists. tomcat run -security gives nullPointerException in jasper/runtime/JspFactoryImpl.java due to no check for pageContext == null in releasePageContext This is fixed in 3.3 if (pc == null) return Rgds Antony -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: 3.2.2. When's it shipping? What is the current state of 3.2.2 development? Is it going to ship any time soon? Dave. [EMAIL PROTECTED]
RE: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
OK, I'll update tomcat.policy to include them. It might be a version difference (I'm using JDK1.2.2) but I can't see any harm with them being there in any case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Glenn Nielsen Sent: Friday, May 18, 2001 11:09 AM To: [EMAIL PROTECTED] Subject: Re: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?] Hmm, I had thought those were getting added automatically, like the read FilePermission for the context root. Sure, you can add those to the default grant policy entry in tomcat.policy. Glenn Marc Saegesser wrote: The null check is simple enough and its already been tested in 3.3 so I feel comfortable making the change without a beta. I'll commit the change today. Another question regarding using the security manager and JSP. If I use the default tomcat.policy file I can't access any JSP pages because I get an access denied expcetion getting the line.separator property. If I add permission java.util.PropertyPermission line.separator, read; permission java.util.PropertyPermission file.separator, read; to tomcat.policy the pages are served correctly. Glenn, is there any problem adding these two lines to the default policy? Am I missing something else? -Original Message- From: Antony Bowesman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 18, 2001 1:50 AM To: [EMAIL PROTECTED] Subject: Re: 3.2.2. When's it shipping? Marc Saegesser wrote: I bloody hope so. Here's the plan. Beta 5 was released on Friday, May 11. This beta cycle is planned for one week. Unless someone reports a show stopping bug, and so far I haven't seen one, on Friday, May 18th. I'll call release vote on tomcat-dev. This vote lasts for one week and every committer gets to vote. A public release vote is open for one week. So, the best case right now is May 28th. Not sure if this would be a showstopper however, there is a bug in jasper/runtime/JspFactoryImpl.java which causes a NullPointerException. Fixed in 3.3 but not in 3.2.2 I'm relatively new to tomcat so am not sure of the bug reporting process but I sent report of a bug to this list a couple of days ago. Just tested it with b5 - bug still exists. tomcat run -security gives nullPointerException in jasper/runtime/JspFactoryImpl.java due to no check for pageContext == null in releasePageContext This is fixed in 3.3 if (pc == null) return Rgds Antony -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: 3.2.2. When's it shipping? What is the current state of 3.2.2 development? Is it going to ship any time soon? Dave. [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
[VOTE] Final release of Tomcat 3.2.2
The latest beta cycle for Tomcat 3.2.2 has completed with no new bugs identified. As the release manager I propose that we release the tomcat_32 branch as Tomcat 3.2.2. Please indicate your vote for the release using the ballot below. I will tabulate and post the results of this vote on Friday, May 25. At that time, if the vote has passed, I will tag, build and distribute the release. The vote must pass by majority approval which means the proposal must receive at least three +1 votes and more +1 votes than -1 votes. Marc Saegesser - Vote to release the tomcat_32 branch as Tomcat 3.2.2. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons.
RE: [VOTE] Final release of Tomcat 3.2.2
Vote to release the tomcat_32 branch as Tomcat 3.2.2. [X] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons.
RE: 3.2.2 mod_jk encoding issue
I just tried this and verified the orginal bug and that the proposed patch
does fix the problem. I'm OK with committing to the tomcat_32 branch.
DOES ANYONE ELSE OUT THERE HAVE ANYTHING THEY WANT TO TELL ME?
Resin would not appear to be compliant with the specification. The 4/27/00
errata indicates that getRequestURI() should return the encoded value.
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 4:31 PM
To: [EMAIL PROTECTED]
Subject: RE: 3.2.2 mod_jk encoding issue
Resin 1.2.5 and 2.0b2 also use uri instead of unparsed_uri.
So what ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 11:27 PM
To: [EMAIL PROTECTED]
Subject: RE: 3.2.2 mod_jk encoding issue
Seems correct to me.
BTW, with the jakarta-tomcat-connector,
this kind of native bugs fixes will appears
outside TC 3.2/3.3/4.0 soon.
I'll correct that on mod_jk in TC 3.3 and
jakarta-tomcat-connector
To be fixed also in mod_webapp.
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 10:10 PM
To: [EMAIL PROTECTED]
Subject: 3.2.2 mod_jk encoding issue
The 2.2 servlet spec errata says the uri from
HttpServletRequest.getRequestURI() should remain encoded.
[http://java.sun.com/products/servlet/errata_042700.html]
Tomcat 3.2 standalone handles this correctly, but the
mod_jk connector does not.
The connector uses the decoded uri from Apache (r-uri).
I believe the correct value to return is the raw, encoded
url (r-unparsed_uri), stripped of the query string, per
the servlet javadoc.
[http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet
/http/HttpSer
vletRequest.html#getRequestURI()]
Of course I will defer to the RM's judgement, but I'd like
to commit the following patch to the 3.2 branch prior to
next Friday:
===
RCS file:
/home/cvs/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
retrieving revision 1.7.2.3
diff -u -r1.7.2.3 mod_jk.c
--- mod_jk.c2001/02/17 05:24:00 1.7.2.3
+++ mod_jk.c2001/05/18 21:05:16
@@ -358,7 +358,13 @@
s-method = (char *)r-method;
s-content_length = get_content_length(r);
s-query_string = r-args;
-s-req_uri = r-uri;
+s-req_uri = r-unparsed_uri;
+if (s-req_uri != NULL) {
+ char *query_str = strchr(s-req_uri, '?');
+ if (query_str != NULL) {
+ *query_str = 0;
+ }
+}
s-is_ssl = JK_FALSE;
s-ssl_cert = NULL;
Ditto for /home/cvs/jakarta-tomcat/src/native/apache2.0/Attic/mod_jk.c
Comments?
Keith
RE: Servlet Upload Data Corruption
Take a look at http://jakarta.apache.org/site/getinvolved.html for
information about contributting to Jakarta projects. Specifically, use
the -u option for generating diffs and send the diffs as attachments instead
of inline.
Could you explain a little more what these diffs accomplish? My
understanding of the fix that went into revision 1.5.2.4 to fix the file
upload problem was that doRead() returns an 'int' and was causing the byte
0xFF to be sign extended into the integer -1 which is the EOF return value
for doRead(). The byte array version of doRead() should only return -1 if
there really isn't any more data. The actualy contents of the bytes read,
because they aren't interpretted, don't matter at all.
I don't see how the byte array returned is any different in the patched
version then what it was before. Converting a byte into a char and then
masking off all but the lowest 8 bits and then turning the results back into
a byte looks like a no-op to me.
-Original Message-
From: DAK [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 16, 2001 10:59 PM
To: [EMAIL PROTECTED]
Subject: Servlet Upload Data Corruption
Here's my first submission! It pertains to Tomcat-3.2.1 and looks to be
the same in 3.2.2.b4
I have some client code that sends a jar file to the servlet. The jar
file was getting corrupted. After much digging, I found a CVS commit to
Ajp13ConnectorRequest.java that mentioned a problem like this with the
doRead() method. It turns out the the same applies to the doRead(byte[],
int, int) method. The same problem exists in the Ajp12ConnectionHandler
for that byte array read. Single byte reads for both protocols work just
fine. I'm including the diffs for these classes to show what I'm talking
about. I may be called a developer now, but I'm certainly not a
commiter, so what is the procedure for getting this fix validated by
somebody else and put into the codebase?
Index: Ajp13ConnectorRequest.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service
/connector/Attic/Ajp13ConnectorRequest.java,v
retrieving revision 1.5.2.7
diff -r1.5.2.7 Ajp13ConnectorRequest.java
274c274,277
System.arraycopy(bodyBuff, pos, b, off, c);
---
//System.arraycopy(bodyBuff, pos, b, off, c);
for (int i=pos, j=off, d=c; d 0; i++, j++, d--) {
b[j] = (byte)(((char)bodyBuff[i])0xff);
}
What I've done here is to replace the array copy with a loop that does
the appropriate data conversion.
Index: Ajp12ConnectionHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/service
/connector/Attic/Ajp12ConnectionHandler.java,v
retrieving revision 1.28.2.4
diff -r1.28.2.4 Ajp12ConnectionHandler.java
542a543,549
public int read(byte b[], int off, int len) throws IOException {
int ret = super.read(b, off, len);
for (int i=0, j=off; ilen; i++, j++) {
b[j] = (byte)(((char)b[j])0xff);
}
return ret;
}
In this case, I over-rode the read method to convert the data after
calling the super.read
I'd like to see this stuff end up in 3.2.2.b5
Thanks,
David Kavanagh
RE: status code 207
What version of Tomcat are you using? From at least Tomcat 3.2.1 that MissingResourceException is caught and handled. If there isn't a message string associated with the result code we send back the status code without the string. Also, in Tomcat 3.2.2 (now in beta) a message string has been added for the 207 status code. -Original Message- From: Murthy Gorty [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 9:35 PM To: [EMAIL PROTECTED] Subject: status code 207 Hi, I need to send a status code of 207 as part of my WebDav-servlet response. But, Tomcat gives me a MissingResourceException because this status code is not defined in org.apache.core.LocalStrings.properties. How do I work around that? What is the standard way of adding custom status codes? Is there a way I can tell Tomcat to use my ResourceBundle that has this status code? snap-shot of the call-stack: java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key sc.207 at java.util.ResourceBundle.getObject(ResourceBundle.java:322) at java.util.ResourceBundle.getString(ResourceBundle.java:298) at org.apache.tomcat.util.StringManager.getString(StringManager.java:136) at org.apache.tomcat.core.ResponseImpl.getMessage(ResponseImpl.java:575) at org.apache.tomcat.service.http.HttpResponseAdapter.endHeaders(Http ResponseAd apter.java:108) at org.apache.tomcat.core.BufferedServletOutputStream.sendHeaders(Buf feredServl etOutputStream.java:126) at org.apache.tomcat.core.BufferedServletOutputStream.reallyFlush(Buf feredServl etOutputStream.java:236) at org.apache.tomcat.core.BufferedServletOutputStream.flush(BufferedS ervletOutp utStream.java:230) Please mailto:[EMAIL PROTECTED] as I dont have subscription to this list. Any help is greatly appreciated. thanks a lot, Murthy
RE: submitting a patch
The guidelines for getting involved in Jakarta projects is described at http://jakarta.apache.org/site/getinvolved.html Submit the patches to the tomcat-dev mailing list and also please create bug report in the bug tracking system and attach your patches there, too. Given the volume of email here, it is too easy for things to slip through the cracks. Sometimes patches won't make it in right away. For example the Tomcat 3.2.2 release if very close to final release. The only things that might go into that code base right now are fixes to show stopper bugs. Once the release is out that code base will be opened up for fixes to less critical bugs. Submitting a bug report will make sure that the fix doesn't get dropped between releases. Keep in mind that this is a volunteer organization and we all have day jobs in addition to working on Tomcat. Sometimes we don't get to things as quickly as we might like, but I don't think we've told anyone to go away. -Original Message- From: Ryan Smith [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 10:13 AM To: [EMAIL PROTECTED] Subject: submitting a patch I have found a bug and fixed it in the Tomcat NT service program. How do I submit it? Do you guys take bug fixes from independent people. I had heard from several people that they had submitted bug fixes and you guys told them to f*** off (not necessarily in those terms). __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: Servlet Upload Data Corruption
rant These 2+ hour email delivery times are getting to be a real pain. It's almost impossible to have multi-party communication with such delays. /rant Revision 1.5.2.4 was commited by Keith and fixed a real problem. doRead() should return the integer -1 when EOF is reached. However, if the byte just read happens to be 0xFF then the conversion from byte to int (for the return) would sign extend the 0xFF value into the integer -1, thus falsely indicating EOF. Casting the byte to a char type avoided the sign extension because chars are unsigned in Java. The byte array filled in by the other doRead() method does not suffer from this problem because the method will only return -1 if there was no more data. Now, the byte array will contain 0xFF bytes and depending on how higher level processing handles them they might cause other problems, but at this layer everything looks OK. That's why I asked for a clarification. I don't see how the proposed changes would actually alter the outcome. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 10:51 AM To: [EMAIL PROTECTED] Subject: RE: Servlet Upload Data Corruption Could you explain a little more what these diffs accomplish? My understanding of the fix that went into revision 1.5.2.4 to fix the file upload problem was that doRead() returns an 'int' and was causing the byte 0xFF to be sign extended into the integer -1 which is the EOF return value for doRead(). Commited by Dan or Keith ?) The byte array version of doRead() should only return -1 if there really isn't any more data. The actualy contents of the bytes read, because they aren't interpretted, don't matter at all. The problem is related to encoding ?) How did the data are then passed (and translated) from byte[] to the servlet ? I don't see how the byte array returned is any different in the patched version then what it was before. Converting a byte into a char and then masking off all but the lowest 8 bits and then turning the results back into a byte looks like a no-op to me. +1
RE: 3.2.2. When's it shipping?
I bloody hope so. Here's the plan. Beta 5 was released on Friday, May 11. This beta cycle is planned for one week. Unless someone reports a show stopping bug, and so far I haven't seen one, on Friday, May 18th. I'll call release vote on tomcat-dev. This vote lasts for one week and every committer gets to vote. A public release vote is open for one week. So, the best case right now is May 28th. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 17, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: 3.2.2. When's it shipping? What is the current state of 3.2.2 development? Is it going to ship any time soon? Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.3 Milestone 3 status
Larry, I just tested this with 3.2.2b5 using Apache, mod_jk and AJP12 and the .jsp%20 problem does indeed exist. When running stand-alone the request returns a 404 error, but with mod_jk the JSP source is returned. If you could port your fix into tomcat_32 that would be great. Let me know what you find. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 2:22 PM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 Milestone 3 status Hi All, I'm in the process of preparing Tomcat 3.3 Milestone 3. Please consider the MAIN branch of jakarta-tomcat frozen for the time being. The current hold up is that mod_jk will serve JSP source for URL's that end with .jsp%20. As soon as I fix this, the Milestone 3 release will soon follow. I'll announce when Tomcat 3.3 development is unfrozen. Cheers, Larry P.S. Marc, a quick scan of mod_jk code didn't reveal differences that would suggest that mod_jk in Tomat 3.2.2 doesn't also have this problem. If there is already a fix, please let me know. Or, if not, let me know if you want me to port my fix. __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc.
RE: Tomcat 3.2.2 : RE : cvs commit: jakarta-tomcat/src/doc readme
Henri, I didn't go for the DNS lookup stuff before was because I felt that it was too large of a change (because it causes external communications) to put it in without a public beta. At the time I was hoping to release 3.2.2 without any more beta cycles. The %00 JSP security problem forced my hand and I had to release another beta. Since I had to the do the beta I went ahead and implemented the DNS lookup for getRemoteHost(), too. I've updated the release notes accordingly. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 5:25 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.2 : RE : cvs commit: jakarta-tomcat/src/doc readme Hi Marc, Could you clarify the getRemoteHost in readme := == == === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name isn't known. (#208) = == == === 7. FIXES AND ENHANCEMENTS IN UPDATES @@ -318,6 +332,8 @@ - HttpServletRequest.encodeURL() now properly encodes URLs that contain an anchor but no query string. (#1182) - Error pages now work in virtual hosts. + - ServletRequest.getRemoteHost() now returns the remote IP address + if the remote host name has not been resolved by web-server. (#208) Regards
RE: Question version 1.1
OK, that goes right to the top of the Why didn't I think of that list. I'll add section to the Tomcat page describing the various releases. -Original Message- From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 3:35 AM To: [EMAIL PROTECTED] Subject: RE: Question version 1.1 Nothing is going on... Tomcat 3.x is the reference implementation of the old Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference implementation of the upcoming new Servlet 2.3/JSP 1.2 APIs. Depending on which API version you want, you might want to try either the 3.2 tree or the 4.0 tree... Maybe something like this should be placed in an impossible to miss place for whomever tries to download/get info on Tomcat. It is the most efficient way to stop USERs confusion. Have fun, Paulo Gaspar -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 8:05 PM To: [EMAIL PROTECTED] Subject: Re: Question version 1.1 Importance: High Michael G. Anderson at [EMAIL PROTECTED] wrote: See Question version 1.0! Is version 3.2.2 beta 5 the latest? or is Tomcat 4(4.4) the latest? What is the latest version? What am I missing? What is going on... Nothing is going on... Tomcat 3.x is the reference implementation of the old Servlet 2.2/JSP 1.1 APIs, while Tomcat 4.x is the reference implementation of the upcoming new Servlet 2.3/JSP 1.2 APIs. Depending on which API version you want, you might want to try either the 3.2 tree or the 4.0 tree... Pier
RE: Java World Editors' Choice Awards
Jon, Sorry, I thought someone had already done that. I'll send Scott my contact info since I'm the one trying to push this puppy out the door. Has anyone else already responded to Scott's email? -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 11:19 AM To: tomcat-dev Subject: Re: Java World Editors' Choice Awards PEOPLE! Reply to Scott! -jon on 5/15/01 2:41 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I will be there also. And yes, it is always nice to put faces to emails. :-) Marc Saegesser wrote: I will be there. I'm looking forwarding to putting faces to lots of names. I *will* get 3.2.2 out the door before I leave for JavaOne. Really, I will. Marc Just ship it Saegesser -Original Message- From: Arieh Markel [mailto:[EMAIL PROTECTED]] Sent: Monday, May 14, 2001 5:53 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FW: Java World Editors' Choice Awards Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Delivered-To: mailing list [EMAIL PROTECTED] User-Agent: Microsoft-Entourage/9.0.1.3108 Subject: FW: Java World Editors' Choice Awards From: Jon Stevens [EMAIL PROTECTED] To: tomcat-dev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] I'm totally amazed no one from here has responded to Scott yet (especially you Sun people). Come on people, please get in touch with him. For what is worth, (having contributed some code to TC 3.2) I will be at JavaOne during that week. Is anybody else going to be present there ? Arieh -jon -- Forwarded Message From: [EMAIL PROTECTED] Date: Mon, 14 May 2001 11:13:13 -0700 To: [EMAIL PROTECTED] Subject: Java World Editors' Choice Awards Jon, I haven't heard from anyone yet. Can you represent Tomcat at the ceremony? It'll be on Tuesday evening , June 5, here in San Francisco. Up to four people can attend. If yes, would you send me your contact information, as outlined in the email below? Regards, Scott - Forwarded by Scott Plamondon/ITWORLD on 05/14/2001 11:13 AM - Dear Jakarta Project, Congratulations! JavaWorld has selected Jakarta Project's Tomcat 3.2 as a finalist in the Most Innovative Java Product category of our Editors' Choice Awards. Established in 1997, the awards recognize those innovative companies, organizations, and individuals committed to developing new Java tools and technologies that drive the platform forward. More than 100 products and technologies were nominated by vendors, readers, as well as JavaWorld editors and writers. We'll publish the complete list of finalists in each category by 5 p.m. PDT on Friday, May 4 (go to: http://www.javaworld.com/jw-05-2001/jw-0504-finalists.html). As a finalist, members of your product team will be invited to attend JavaWorld's Editors' Choice Awards ceremony at the JavaOne Conference and Expo from June 4-8 in San Francisco, where a winner in each category will be announced. Invitations to the ceremony, with the date and location, will be mailed in mid-May. With that in mind, I need to confirm your organization's contact information. Please let me know to whom we should send the invitation at your earliest convenience: Contact Name: Title: Product Name: Address: City, State, Zip: Phone: Email: If you have any questions, please don't hesitate to email me at this address or call 415-975-2651. Regards, Scott Plamondon Senior Editor JavaWorld [EMAIL PROTECTED] 415-975-2651 -- End of Forwarded Message -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Pray for snow Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key) -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
