Re: quick_handler hook is completely bogus.

2002-07-31 Thread Graham Leggett
Ryan Bloom wrote: 1) If I have a page that I have served and it gets put in the cache, then it will be served out of the quick_handler phase. However, if I then add or modify a .htaccess file to deny access to that page, then my changes won't be honored until the page expires from the

Re: quick_handler hook is completely bogus.

2002-07-31 Thread Graham Leggett
Ryan Bloom wrote: mod_proxy doesn't use the quick_handler. Not mod_proxy, mod_cache. Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street

RE: quick_handler hook is completely bogus.

2002-07-31 Thread Bill Stoddard
Ryan Bloom wrote: 1) If I have a page that I have served and it gets put in the cache, then it will be served out of the quick_handler phase. However, if I then add or modify a .htaccess file to deny access to that page, then my changes won't be honored until the page expires from

Re: cvs commit: httpd-2.0 STATUS

2002-07-31 Thread Greg Ames
[EMAIL PROTECTED] wrote: +* Performance problems in the content-length filter: + - In addition, the C-L filter reads and buffers all the +content from a pipe bucket. What could we do instead? Punt on the length any time there's a pipe bucket? Greg

RE: quick_handler hook is completely bogus.

2002-07-31 Thread Ryan Bloom
I agree with everything that Brian said, and he put it far better than I could have. I would be MUCH happier with the quick_handler phase if it occurred after the AAA phases. Potentially, this could be achieved, and the performance could be improved by simply having the cache module register a

SSLMutex directive, PR 8122

2002-07-31 Thread Jeff Trawick
This PR points out a problem with the current SSLMutex handling in mod_ssl and provides a patch to resolve it. I'd rather see a different solution: 1) give SSLMutex the same syntax as AcceptMutex, except that SSLMutex has an additional choice: none. 2) add SSLMutexFile which is processed

RE: SSLMutex directive, PR 8122

2002-07-31 Thread Ryan Bloom
This PR points out a problem with the current SSLMutex handling in mod_ssl and provides a patch to resolve it. I'd rather see a different solution: 1) give SSLMutex the same syntax as AcceptMutex, except that SSLMutex has an additional choice: none. 2) add SSLMutexFile which is

Re: SSLMutex directive, PR 8122

2002-07-31 Thread Dale Ghent
On 31 Jul 2002, Jeff Trawick wrote: | This PR points out a problem with the current SSLMutex handling in | mod_ssl and provides a patch to resolve it. | | I'd rather see a different solution: | | 1) give SSLMutex the same syntax as AcceptMutex, except that SSLMutex |has an additional choice:

RE: quick_handler hook is completely bogus.

2002-07-31 Thread Bill Stoddard
I agree with everything that Brian said, and he put it far better than I could have. I would be MUCH happier with the quick_handler phase if it occurred after the AAA phases. Potentially, this could be achieved, and the performance could be improved by simply having the cache module

2.0.40 -- again

2002-07-31 Thread Ian Holsman
with the recent fix to apr_poll's memory leak we can start this ball rolling again.. I'll tag the 2.0.40 as the existing stuff tagged + this poll. is there any other small patches which need/should go into 40 since I last tagged ? TIA Ian

Re: cvs commit: httpd-2.0 STATUS

2002-07-31 Thread Brian Pane
Greg Ames wrote: [EMAIL PROTECTED] wrote: +* Performance problems in the content-length filter: + - In addition, the C-L filter reads and buffers all the +content from a pipe bucket. What could we do instead? Punt on the length any time there's a

Re: 2.0.40 -- again

2002-07-31 Thread Jeff Trawick
Ian Holsman [EMAIL PROTECTED] writes: with the recent fix to apr_poll's memory leak we can start this ball rolling again.. We'll need to state that it can't be used with x Listen statements or explain how to build APR to allow more descriptors with no memory leak in apr_poll. I'll tag the

Re: 2.0.40 -- again

2002-07-31 Thread Brian Pane
Ian Holsman wrote: with the recent fix to apr_poll's memory leak we can start this ball rolling again.. I'll tag the 2.0.40 as the existing stuff tagged + this poll. is there any other small patches which need/should go into 40 since I last tagged ? I can think of a few things to add:

Re: 2.0.40 -- again

2002-07-31 Thread Brian Pane
Jeff Trawick wrote: Ian Holsman [EMAIL PROTECTED] writes: with the recent fix to apr_poll's memory leak we can start this ball rolling again.. We'll need to state that it can't be used with x Listen statements or explain how to build APR to allow more descriptors with no memory leak

Re: 2.0.40 -- again

2002-07-31 Thread Jeff Trawick
Brian Pane [EMAIL PROTECTED] writes: Jeff Trawick wrote: Ian Holsman [EMAIL PROTECTED] writes: with the recent fix to apr_poll's memory leak we can start this ball rolling again.. We'll need to state that it can't be used with x Listen statements or explain how to build APR to

Re: 2.0.40 -- again

2002-07-31 Thread Ian Holsman
Jeff Trawick wrote: Ian Holsman [EMAIL PROTECTED] writes: with the recent fix to apr_poll's memory leak we can start this ball rolling again.. We'll need to state that it can't be used with x Listen statements or explain how to build APR to allow more descriptors with no memory leak

Re: CGI 1.1 Compliance wrt CGI-sent status codes.

2002-07-31 Thread Rodent of Unusual Size
Waldo Van Cleef wrote: Apache 1.3.x breaks the CGI 1.1 specification with its handling of script-generated status codes. It appears to work in the case of status 302, but this appearance is only maintained via an uncoditional redirect in the cast that the location header is set and an

forget quick_handler, make stuff cachable anyways

2002-07-31 Thread Brian Degenhardt
Just wanted to voice my opinion here. I do a lot of work with caching proxies and it would be really nice to have apache be intelligent to how things are cached. There's two types of changes that would really help caches and proxies, internal and external to apache: 1) Make apache modules add

mod_cache's hash table question

2002-07-31 Thread Ian Holsman
it seems to have a memory leak. when you remove an entry from the hash table, there seems to be no method to free the memory used by the key field, as there is no way to retrieve that pointer back from the current api. now we have 2 choices from what I can see. * copy the key when we 'set' it

[STATUS] (apache-1.3) Wed Jul 31 23:45:06 EDT 2002

2002-07-31 Thread Rodent of Unusual Size
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/06/27 20:57:21 $] Release: 1.3.27-dev: In development 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22,

[STATUS] (httpd-2.0) Wed Jul 31 23:45:11 EDT 2002

2002-07-31 Thread Rodent of Unusual Size
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/07/31 05:30:12 $] Release: 2.0.40 : in development. 2.0.39 : rolled June 17, 2002. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not

apache 2 disk-cache SEGV

2002-07-31 Thread Eric Prud'hommeaux
Has anybody seen --enable-disk-cache or --enable-mem-cache work under apache 2? In my scenario: --enable-maintainer-mode --with-mpm=prefork --enable-rewrite --enable-expires --enable-speling --disable-auth --enable-headers --enable-info --disable-userdir --enable-dav --enable-proxy

Duplicate headers in apache 2 disk-cache

2002-07-31 Thread Eric Prud'hommeaux
Resources served by proxy after consulting a stale cache have duplicates of the non-specially handled headers. This is because mod_disk_cache's read_headers reads the cached headers into the err_headers_out and ap_http_header_filter merges them with the ones read from a proxy call.