DO NOT REPLY [Bug 36083] - can't configure nested applications

2005-08-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36083. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 36083] - can't configure nested applications

2005-08-18 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36083. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Graham Dumpleton
A few comments: 1. If you have an older version of flex than that expected, it gives message: checking flex version... configure: WARNING: Flex version 2.5.31 or greater is required. The one you have seems to be 2.5.4. Use --with-flex to specify another. There is nothing in the README

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Ron Reisor
Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the -undefined suppress arguments in the final load. I modified dist/setup.py by removing the two -undefined suppress and ran configure and make again and the new

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Nicolas Lehuen
+1 on Win32 with Python 2.4. Here is how I tested it : 1) Switched to the 3.2.0-BETA tag 2) Update 3) cd dist build_installer.bat 4) Got this installer, that you can also download : http://nicolas.lehuen.com/download/mod_python/mod_python-3.2.0-BETA.win32-py2.4.exe 5) Ran the installer,

Re: flex [was mod_python 3.2.0-BETA available for testing]

2005-08-18 Thread Jim Gallacher
Gregory (Grisha) Trubetskoy wrote: OK, here is the flex scoop - as the the docs point out, anything before 2.5.31 is not reentrant and I think even uses a slightly different interface so older flex won't even process the psp_parser.l file correctly. Looking at Fedora Core 4, it still has

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Graham Dumpleton
On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the -undefined suppress arguments in the final load. I modified dist/setup.py by removing the two

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Colm MacCarthaigh
On Wed, Aug 17, 2005 at 03:17:41PM -0700, Justin Erenkrantz wrote: Content definitely should not be served from the cache after it has expired imo. However I think an approach like; if((now + interval) expired) { if(!stat(tmpfile)) { update_cache_from_backend();

Re: Rolling 2.1.7 On Friday

2005-08-18 Thread Joe Orton
On Wed, Aug 17, 2005 at 10:43:01PM -0700, Paul Querna wrote: Just a heads up, I am planning to RM and tag 2.1.7 (and re-branch from trunk the 2.2.x branch) on Friday or Saturday this week. I intend to include APR and APR-Util 1.2.1 with this release. Sounds great. Can you exclude the

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Brian Akins
Jim Jagielski wrote: Would be interesting to profile that to determine how expensive those stats could be... Should be much less expensive than the case now -- the thundering herd when an object expires. Of course, the behavior would be configurable. -- Brian Akins Lead Systems

Re: [PATCH] mod_cache. Allow override of some vary headers

2005-08-18 Thread Brian Akins
[EMAIL PROTECTED] wrote: What sort of testing did you do in those few hours? That's why I posted it, to get some more input. If I could play devil's advocate for a moment... my concern would be that you haven't considered certain scenarios that won't work with this patch. Most of the

Re: [PATCH] mod_cache. Allow override of some vary headers

2005-08-18 Thread Brian Akins
Here's a new patch that changes the option name to CacheVaryOverride and does some of the stuff Justin recommened. -- Brian Akins Lead Systems Engineer CNN Internet Technologies diff -ru httpd-trunk.orig/modules/cache/cache_storage.c httpd-trunk.new/modules/cache/cache_storage.c ---

[PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
This one's kinda ugly. Rather than rely on apr_file_gets, this stores the total length of the tables, then the serialized table in store_table. In read_table, it reads this length, allocs that amount, and reads the headers into the buffer. Then it just uses memchr to parse it into a table.

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Jim Gallacher
Graham Dumpleton wrote: A few comments: 1. If you have an older version of flex than that expected, it gives message: checking flex version... configure: WARNING: Flex version 2.5.31 or greater is required. The one you have seems to be 2.5.4. Use --with-flex to specify another. There is

[PATCH] mod_disk_cache, only cache req_hdrs if vary

2005-08-18 Thread Brian Akins
Some more low hanging fruit. This moves varray into disk_cache_object_t and only writes out/reads in the request headers if the response actually varied. An easy 4-7% performance boost in my tests for responses with no vary. -- Brian Akins Lead Systems Engineer CNN Internet Technologies

Re: flex [was mod_python 3.2.0-BETA available for testing]

2005-08-18 Thread Gregory (Grisha) Trubetskoy
OK, here is the flex scoop - as the the docs point out, anything before 2.5.31 is not reentrant and I think even uses a slightly different interface so older flex won't even process the psp_parser.l file correctly. Looking at Fedora Core 4, it still has flex 2.5.4a. (Note that 2.5.31

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 09:22:13AM -0400, Brian Akins wrote: Thanks to all who reminded me what a dumb-a## I am this morning... I forgot the patch. Here it is. Cool. diff -ru httpd-trunk.orig/modules/cache/mod_disk_cache.c httpd-trunk.new2/modules/cache/mod_disk_cache.c ---

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Colm MacCarthaigh wrote: I can understand why this is faster, I'm guessing that you've enough RAM that you're retrieving files from the vmcache and that the higher-layer buffering is just overhead. This is probably going to be the majority case, but would do with testing. Not to heap more

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 10:43:41AM -0400, Brian Akins wrote: I can understand why this is faster, I'm guessing that you've enough RAM that you're retrieving files from the vmcache and that the higher-layer buffering is just overhead. This is probably going to be the majority case, but would do

Apache 2.1 on Win32 nightmare

2005-08-18 Thread Günter Knauf
Hi all, as we discussed more than once here on the list the latest sources require that one has LDAP 3.0 support in the platform SDK. I was not able to get that ldap 3.0 piece to fit into the platform sdk for MSVC6, so I'm for longer no more able to build 2.1 or later self. So I asked another

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Colm MacCarthaigh wrote: Thinking about it, everything is going into memory anyway, so why not just stat() the file and read it all in in one go? Yes! Brilliant. We need all that data anyway. so: open file. length = get_info read_full(file, length). manipulate pointers for table

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 12:11:56PM -0400, Brian Akins wrote: Yep, but there are definite speed-up's to be had. I'm going to canibalise your patch and try some of the above anyway. Cool. I'd be willing to help. I'll be putting on-line all of my TODO's and patches-in-progress shortly, I have

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Colm MacCarthaigh wrote: Do you mean as in using MAP_SHARED? I could see that being a race-condition nightmare. For example cache_info_t's pointers to the header tables would have to be local to the process, but the memory for the cache_info_t itself wouldn't be. Definitely to be avoided!

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Jeff Trawick
On 8/18/05, Brian Akins [EMAIL PROTECTED] wrote: I didn't mess with the EBCDIC stuff, so alot of the patch is just where I commented all that out. The EBCDIC stuff came here: http://svn.apache.org/viewcvs.cgi?rev=105236view=rev Apparently Justin needed logic similar to

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Justin Erenkrantz
--On August 18, 2005 3:59:05 PM +0100 Colm MacCarthaigh [EMAIL PROTECTED] wrote: Thinking about it, everything is going into memory anyway, so why not just stat() the file and read it all in in one go? We know it's never going to be that big anyway. This completely minimises the number of

Re: mod_python 3.2.0-BETA available for testing

2005-08-18 Thread Jim Gallacher
Ron Reisor wrote: Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the -undefined suppress arguments in the final load. I modified dist/setup.py by removing the two -undefined suppress and ran configure and make

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Justin Erenkrantz
--On August 18, 2005 9:24:57 AM +0100 Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Aug 17, 2005 at 03:17:41PM -0700, Justin Erenkrantz wrote: Content definitely should not be served from the cache after it has expired imo. However I think an approach like; if((now + interval)

Re: mod_cache recall_body

2005-08-18 Thread Justin Erenkrantz
--On August 18, 2005 9:55:57 AM -0400 Brian Akins [EMAIL PROTECTED] wrote: Why do we pass request_rec to recall_headers, but not to recall_body. We also always pass r-pool. How horrible would it be if the prototype was changed to: apr_status_t (*recall_body) (cache_handle_t *h, request_rec

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 10:07:29AM -0700, Justin Erenkrantz wrote: Okay. I see what you mean now. If the interval is configurable via a directive, then yes that makes sense. This could be done independently of deterministic tempfiles. It could, though it would require using a seperate

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Justin Erenkrantz wrote: But, that's why we do the buffered read. It almost always ends up being one read() for me as the header file is always less than 4k. True. I don't believe we should necessarily optimize based on the results of one platform when we know its going to kill us

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Justin Erenkrantz
--On August 18, 2005 1:34:56 PM -0400 Brian Akins [EMAIL PROTECTED] wrote: The optimizations that Colm is talking about should be helpful everywhere. Also, that's why we test to make sure it does kill us. Also, I don't think we know it will kill us. None of the code in mod_disk_cache used

[PATCH] Re: mod_cache recall_body

2005-08-18 Thread Brian Akins
Justin Erenkrantz wrote: I'd be fine with it matching store_body's prototype. (Which is what you have.) -- justin Here's a patch that does this. -- Brian Akins Lead Systems Engineer CNN Internet Technologies diff -ru httpd-trunk.orig/modules/cache/mod_cache.c

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Justin Erenkrantz wrote: None of the code in mod_disk_cache used buffering before I turned it on. It gave significant speedups in my performance tests by reducing the syscall overhead. I also had identified and fixed some bugs in apr's buffering code to go along with these speedups that

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 10:43:45AM -0700, Justin Erenkrantz wrote: None of the code in mod_disk_cache used buffering before I turned it on. It gave significant speedups in my performance tests by reducing the syscall overhead. I also had identified and fixed some bugs in apr's buffering

Re: [PATCH] mod_disk_cache: speed up read_table

2005-08-18 Thread Brian Akins
Colm MacCarthaigh wrote: The optimisations wouldn't be removing buffering, they'd be using a different kind of buffering :-) If MMap is not available/enabled we can fail back to a buffered APR read. So it's evolved even further... I would be interested to see in a variety of cases which one

input filter problems

2005-08-18 Thread Martijn Faassen
Hi there, I've spent the last few days trying to get an input filter to work in mod_python, in the context of requests that are being reverse proxied to an app-server by mod_proxy. I've also tried mod_rewrite. The input filter works fine if mod_proxy or mod_rewrite are *not* in play and

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 01:39:18PM -0400, Brian Akins wrote: Dead process is solveable with IPC, the existing locking schemes should be enough for this. The hard problem I think is when a backend has stalled. Can't think of an easy fix for that case. When you stat the temp file, if its

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Brian Akins
Colm MacCarthaigh wrote: So mtime not being recent is no-indication of death, it could easily be a trickling download. True. But, if the files mtime has not changed in 120 seconds (for example) the download is probably hung? -- Brian Akins Lead Systems Engineer CNN Internet Technologies

Re: [PATCH] mod_disk_cache deterministic tempfiles

2005-08-18 Thread Colm MacCarthaigh
On Thu, Aug 18, 2005 at 02:00:52PM -0400, Brian Akins wrote: Colm MacCarthaigh wrote: So mtime not being recent is no-indication of death, it could easily be a trickling download. True. But, if the files mtime has not changed in 120 seconds (for example) the download is probably hung?

canonical port

2005-08-18 Thread Brian Akins
We have servers that listen on a ports other than 80 which our load balancers communicate with. The client hits port 80 on the load balancer. I hacked up a quick module to try to emulate the old Port config directive so that redirects go to the canonical port. It does this by changing

Re: canonical port

2005-08-18 Thread Sander Temme
Brian, On Aug 18, 2005, at 11:45 AM, Brian Akins wrote: We have servers that listen on a ports other than 80 which our load balancers communicate with. The client hits port 80 on the load balancer. I hacked up a quick module to try to emulate the old Port config directive so that

Re: canonical port

2005-08-18 Thread Brian Akins
Sander Temme wrote: Do you do more/different things? This is what I do in translate_name: if((conf = ap_get_module_config(r-server-module_config, port_module)) != NULL) { if(conf-port != NOCONFIG) { /*looking at server/core.c, ap_get_server_port This looks to be the

[STATUS] (httpd-2.0) Wed Aug 17 23:45:26 2005

2005-08-18 Thread Rodent of Unusual Size
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-08-11 05:57:40 -0400 (Thu, 11 Aug 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is

[STATUS] (httpd-2.1) Wed Aug 17 23:45:30 2005

2005-08-18 Thread Rodent of Unusual Size
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-06-30 16:42:43 -0400 (Thu, 30 Jun 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Documentation status is maintained

[STATUS] (httpd-test: flood) Wed Aug 17 23:45:43 2005

2005-08-18 Thread Rodent of Unusual Size
flood STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001

[STATUS] (httpd-test: perl-framework) Wed Aug 17 23:45:47 2005

2005-08-18 Thread Rodent of Unusual Size
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the

Re: canonical port

2005-08-18 Thread Brian Akins
Hmm, it seems if useCanonicalName is off and you use Servername like this: ServerName www.domain.com:80 That ap_get_servername will use that port unless the client used a port in the Host: header. My testing seems to confirm this. Is this correct? -- Brian Akins Lead Systems Engineer

Re: [STATUS] (httpd-2.1) Wed Aug 17 23:45:30 2005

2005-08-18 Thread Brian Akins
Rodent of Unusual Size wrote: * mod_cache: Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache will cache #include 'virtual' requests (but not #include 'file' requests). This was accomplished by

Re: svn commit: r233369 - /httpd/httpd/trunk/modules/mappers/mod_dir.c

2005-08-18 Thread William A. Rowe, Jr.
-1. If what the PR you fixed wanted to avoid mod_cgi, or the core handler dealing with the request, then the correct answer was to have those modules reject this request. Now I expect you've just hijacked the request away from tomcat via mod_jk among other methods for a module to substitute

Re: svn commit: r233369 - /httpd/httpd/trunk/modules/mappers/mod_dir.c

2005-08-18 Thread Paul Querna
William A. Rowe, Jr. wrote: -1. If what the PR you fixed wanted to avoid mod_cgi, or the core handler dealing with the request, then the correct answer was to have those modules reject this request. Now I expect you've just hijacked the request away from tomcat via mod_jk among other

Some RFC 2616 questions

2005-08-18 Thread Wilfredo Sánchez Vega
The spec for If-{None-}Match and If-{Un}Modified-Since is driving me batty. The biggest item has to do with having to know the response code for the request without processing the request. Specifically, 14.24 (If-Match) and the others have a requirement like: If the request

Supporting RBL in mod_smtpd

2005-08-18 Thread Jem Berkes
Here is my current plan for introducing the RBL support in mod_smtpd, using the existing mod_dnsbl_lookup which I posted earlier. This way of accomplishing the RBL support should not require any code modification to mod_smtpd itself. Nick and Rian, let me know if I should be going about this a

Re: Supporting RBL in mod_smtpd

2005-08-18 Thread Rian Hunter
On Aug 18, 2005, at 7:11 PM, Jem Berkes wrote: Here is my current plan for introducing the RBL support in mod_smtpd, using the existing mod_dnsbl_lookup which I posted earlier. This way of accomplishing the RBL support should not require any code modification to mod_smtpd itself. Nick and

Re: Rolling 2.1.7 On Friday

2005-08-18 Thread William A. Rowe, Jr.
At 03:36 AM 8/18/2005, Joe Orton wrote: On Wed, Aug 17, 2005 at 10:43:01PM -0700, Paul Querna wrote: Just a heads up, I am planning to RM and tag 2.1.7 (and re-branch from trunk the 2.2.x branch) on Friday or Saturday this week. I intend to include APR and APR-Util 1.2.1 with this release.

Re: Supporting RBL in mod_smtpd

2005-08-18 Thread Jem Berkes
smtpd_run_connect (might deny service to connecting IP, per request_rec) smtpd_run_mail (might deny service to this envelope domain, per loc) +1 ... Don't do this just yet, mod_smtpd is changing completely! completely = structures/io. I should commit my changes very soon so you can

Re: Rolling 2.1.7 On Friday

2005-08-18 Thread William A. Rowe, Jr.
At 12:43 AM 8/18/2005, Paul Querna wrote: Just a heads up, I am planning to RM and tag 2.1.7 (and re-branch from trunk the 2.2.x branch) on Friday or Saturday this week. I intend to include APR and APR-Util 1.2.1 with this release. Note you can't tag the recent commit to mod_dir, there is a veto

Re: Rolling 2.1.7 On Friday

2005-08-18 Thread William A. Rowe, Jr.
[EMAIL PROTECTED]'ers... As Paul mentions below, on Friday (probably 1 a.m. ;-) he will tag 2.1.7. This is just a reminder to our most excellent doco team that, once ack'ed - this becomes 2.1 beta, and then... (drum roll please...) 2.2 GA(!) So if you had changes to catch up with 2.1 that

Re: Rolling 2.1.7 On Friday

2005-08-18 Thread Paul Querna
William A. Rowe, Jr. wrote: At 12:43 AM 8/18/2005, Paul Querna wrote: Just a heads up, I am planning to RM and tag 2.1.7 (and re-branch from trunk the 2.2.x branch) on Friday or Saturday this week. I intend to include APR and APR-Util 1.2.1 with this release. Note you can't tag the recent