Re: cvs commit: httpd-2.0 CHANGES

2002-07-14 Thread Brian Pane
Aaron Bannert wrote: >On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote: > > >>It's >>unreasonable to make the every admin responsible for hacking >>their start scripts to work around our broken product. >> >> > >In what way is our product broken? > Well, threaded MPMs or large vh

Re: Faster time_now() [Was: Why not POSIX time_t?]

2002-07-14 Thread Ryan Bloom
On Mon, 15 Jul 2002, William A. Rowe, Jr. wrote: > At 10:03 PM 7/14/2002, Ryan Bloom wrote: > > >BTW, this whole conversation started because we wanted to speed up > >Apache. Has anybody considered taking a completely different tack to > >solve this problem? > > > >I know there is a patent on t

Faster time_now() [Was: Why not POSIX time_t?]

2002-07-14 Thread William A. Rowe, Jr.
At 10:03 PM 7/14/2002, Ryan Bloom wrote: >BTW, this whole conversation started because we wanted to speed up >Apache. Has anybody considered taking a completely different tack to >solve this problem? > >I know there is a patent on this, but I am willing to ignore it, and I >am pretty sure that w

Re: cvs commit: httpd-2.0 CHANGES

2002-07-14 Thread Aaron Bannert
On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote: > It's > unreasonable to make the every admin responsible for hacking > their start scripts to work around our broken product. In what way is our product broken? In order to use our product in certain ways your system may have to be con

Re: cvs commit: httpd-2.0 CHANGES

2002-07-14 Thread Brian Pane
Aaron Bannert wrote: >I really don't like this. It adds unnecessary complexity to the configure >script, > There's nothing unnecessary about it. > misleads admins in to thinking that they have to rerun configure >to set the file limit, > No, nowhwere do we say "you have to rerun configure to s

Re: cvs commit: httpd-2.0 CHANGES

2002-07-14 Thread Aaron Bannert
I really don't like this. It adds unnecessary complexity to the configure script, misleads admins in to thinking that they have to rerun configure to set the file limit, and does something that should just be set by the admin themselves at starttime. -aaron On Sun, Jul 14, 2002 at 11:18:46PM -0

Re: httpd-ldap maintained?

2002-07-14 Thread Scott Lamb
Graham Leggett wrote: > Ok... worker is threaded? (I don't know my MPM's, been focusing on the > other modules). Yes, worker is threaded. But I was wrong - it has the same problem as with prefork. I think I was not as brutal the first time I tested with worker; see below. >> Connections accum

Re: content-length filter and r->bytes_sent

2002-07-14 Thread Brian Pane
Ryan Bloom wrote: >>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] >> >>At 02:51 AM 7/14/2002, you wrote: >> >> >>>Currently, the content-length filter attempts to compute the length >>>of the entire response before passing any data on to the next filter, >>>and it sets request_rec->by

RE: content-length filter and r->bytes_sent

2002-07-14 Thread Ryan Bloom
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > At 02:51 AM 7/14/2002, you wrote: > >Currently, the content-length filter attempts to compute the length > >of the entire response before passing any data on to the next filter, > >and it sets request_rec->bytes_sent to the computed cont

Re: content-length filter and r->bytes_sent

2002-07-14 Thread William A. Rowe, Jr.
At 02:51 AM 7/14/2002, you wrote: >Currently, the content-length filter attempts to compute the length >of the entire response before passing any data on to the next filter, >and it sets request_rec->bytes_sent to the computed content-length. The real answer is simple. C-L filter should only set

Re: content-length filter and r->bytes_sent

2002-07-14 Thread William A. Rowe, Jr.
At 02:51 AM 7/14/2002, you wrote: >Currently, the content-length filter attempts to compute the length >of the entire response before passing any data on to the next filter, >and it sets request_rec->bytes_sent to the computed content-length. > > * r->bytes_sent is used by mod_log_config as a co

Re: content-length filter and r->bytes_sent

2002-07-14 Thread Brian Pane
On Sun, 2002-07-14 at 09:35, Cliff Woolley wrote: > On Sun, 14 Jul 2002, Brian Pane wrote: > > > For example, given a .shtml file that includes several small, > > non-parsed files, the setaside logic in the C-L filter will do > > an mmap+memcpy+munmap of each of the included files. >

Re: content-length filter and r->bytes_sent

2002-07-14 Thread Cliff Woolley
On Sun, 14 Jul 2002, Brian Pane wrote: > For example, given a .shtml file that includes several small, > non-parsed files, the setaside logic in the C-L filter will do > an mmap+memcpy+munmap of each of the included files. All that needs to happen here is that file_bucket_setaside()

content-length filter and r->bytes_sent

2002-07-14 Thread Brian Pane
Currently, the content-length filter attempts to compute the length of the entire response before passing any data on to the next filter, and it sets request_rec->bytes_sent to the computed content-length. This is bad for several reasons: * The C-L filter needs to know the length of every buck