Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Mark Thomas wrote: Single ajp13 worker jkMount /jsp-examples/* worker1 A simple 'hello world' html file was created at (directories created where required): /jsp-examples/%2e%2e/servlets-examples/index.html Test 1: Tomcat only http://localhost:8080/jsp-examples/%252e%252e/servlets-examples/i

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Mladen Turk wrote: > Mark Thomas wrote: >> >>> Did I mention that uri is *not* decoded twice? >> >> You did and I still don't agree. The root cause of CVE-2007-1860 was a >> double decoding. Once in httpd/mod_jk and once in Tomcat. >> > > Why do you don't agree? > Please provide a use case and con

commons-collections is downloaded but never used

The tomcat build downloads commons-collections but never uses it. It seems this could be removed from the build scripts -Original Message- From: Mark Claassen [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 1:24 PM To: dev@tomcat.apache.org Subject: MD5 checksums when building T

DO NOT REPLY [Bug 42608] New: - Invalid Content-Length error for the binary file size greater than 2.1GB

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

MD5 checksums when building Tomcat from source

I am trying to build Tomcat from source and I am curious about something. On the Tomcat download page it say the following: > "You must verify the integrity of the downloaded files." Yet, the Tomcat build blindly downloads all kinds of sources that are not verified in any way. ANT can do MD5 chec

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Remy Maucherat wrote: Mark Thomas wrote: As I see it, we have two options: a) Prevent Tomcat from decoding the uri a second time at step 7 above b) Re-encode the uri in mod_jk between steps 5 and 6 I think: - it's the proxy which should have options for adapting to what the proxied server do

Developing Tomcat in NB

Dear Tomcat developers, I would like to let you now that we have recently ported Tomcat 6.0.13 environment into NetBeans IDE. You may wish to check it out: http://wiki.netbeans.org/wiki/view/NetbeansedTomcat If you are new to NB please go to netbeans.org for all information, tutorials and fun st

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Mark Thomas wrote: As I see it, we have two options: a) Prevent Tomcat from decoding the uri a second time at step 7 above b) Re-encode the uri in mod_jk between steps 5 and 6 The problem with b) is that we can't easily tell what characters were previously encoded and need to be re-encoded. b) i

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Mark Thomas wrote: Did I mention that uri is *not* decoded twice? You did and I still don't agree. The root cause of CVE-2007-1860 was a double decoding. Once in httpd/mod_jk and once in Tomcat. Why do you don't agree? Please provide a use case and confirm your statements are legitimate.

Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c

Mladen Turk wrote: > Mark Thomas wrote: >>> mod_jk 1.2.23 (with default passing r->unparsed_uri) will return 404 >>> from Tomcat becasue it will pass the original uri, not the one Httpd >>> already unfolded) >> This is correct and provides consistent behaviour for direct to Tomcat >> access and ac

DO NOT REPLY [Bug 42488] - in HP-UX the getter and setter for a property is not recognized.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r544807 - in /tomcat/site/trunk: docs/security-6.html xdocs/security-6.xml

Author: markt Date: Wed Jun 6 04:21:17 2007 New Revision: 544807 URL: http://svn.apache.org/viewvc?view=rev&rev=544807 Log: Correct fixed in version for CVE-2005-2090 Modified: tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/xdocs/security-6.xml Modified: tomcat/site/trunk/docs

Re: jk/native/common/jk_uri_worker_map.c Efficiency in map_uri_to_worker()?

On Tue, 2007-06-05 at 17:15 -0500, Webster, Chris wrote: > The code change was brought to my attention by sans.org (for > vulnerability CVE 2007-0774). No offense intended but the fix seems a > little inefficient. You fix is bad Because we only need the url: part of the uri before the ';' so