Re: [PATCH] resubmit new and improved ap_vrprintf fix to handle > 4K

> > /* this will typically exit on the first test */ > > for (f = r->output_filters; f != NULL; f = f->next) > > if (strcasecmp("OLD_WRITE", f->frec->name) == 0) > > break; > > > > i'm puking. strcasecmp strings?? > > Yah :-) It could be optimized by recording a f

Re: [PATCH] resubmit new and improved ap_vrprintf fix to handle > 4K

Yeah, the OLD_WRITE filter removes a lot of the optimizations we should be able to get with the filtering logic. If you take a look at the apr_brigade_* functions, you will see a more direct way to do this stuff. We get direct access to the buffers, and assuming the buffer was already allocated

Re: [PATCH] resubmit new and improved ap_vrprintf fix to handle > 4K

On Mon, Sep 10, 2001 at 09:13:46PM -0700, dean gaudet wrote: > buhhh? > > you guys built a zero-copy infrastructure and you're putting in a one-copy > sprintf? sprintf varieties must be at least one-copy, based on our vformatter code (which BUFF used, too). It seems you're implying sprintf shoul

Re: chunking of content in mod_include?

On Monday 10 September 2001 18:02, dean gaudet wrote: > On Mon, 27 Aug 2001, Ryan Bloom wrote: > > I don't care if mod_include buffers 200 Megs, as long as it is constantly > > doing something with the data. If we have a 200 Meg file that has no SSI > > tags in it, but we can get all 200 Meg at o

Re: [PATCH] Cleaning mod_cgi.c

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 11:16 PM > The default_build_command code I dropped in should cover the unix (and suexec) > case, but there were some odd discrepancies amoungst all the code repetition. > It folds the old, seperate command and arg

Re: Apache-1.3: question about mod_unique_id

From: "dean gaudet" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 8:26 PM > On Fri, 24 Aug 2001, Günter Knauf wrote: > > > Hi, I've compiled mod_unique_id for Win32 and for Netware, and on both > > platforms it seems to work the same as with Unix, I can see a unique > > id with SSI and cg

[PATCH] Cleaning mod_cgi.c

Since Brane has picked up on my efforts to cleanup the apr_proc_create fooness, I'd like to push to clean this out sooner rather than later. The ap_cgi_build_command optional function would be implemented on platforms that don't like the 'unix' way of building the command and argv[] for cgi app

Re: [PATCH] resubmit new and improved ap_vrprintf fix to handle >4K

buhhh? you guys built a zero-copy infrastructure and you're putting in a one-copy sprintf? i don't get it. this new ap_rsprintf is less efficient than the ap_bsprintf in apache-1.3. also, wow, ap_rputc really sucks now. that's a lot of code (in buffer_output) compared to: *buf++ = c; gu

Re: cvs commit: apache-1.3/src/modules/standard mod_auth.c

From: <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 10:29 PM > coar01/09/10 20:29:11 > > Modified:.STATUS >src CHANGES >src/modules/standard mod_auth.c > Log: > get*id() don't work on Windows; thanks to OtherBill for pointing

Re: Optimizing dir_merge()

From: "dean gaudet" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 10:39 PM > On Wed, 15 Aug 2001, Brian Pane wrote: > > > William A. Rowe, Jr. wrote: > > > > >Here's my take on the dir_merge patch I offered up. Please review for sanity. > > > > There's one point at the end where I disag

Re: Optimizing dir_merge()

On Wed, 15 Aug 2001, William A. Rowe, Jr. wrote: > . If the pool argument passed in merge_dir_configs doesn't match the base config, > it's out of scope! You must copy when the pool argument differs from the base! > > . Likewise, if you are changing parts of the add config, and the add c

Re: Optimizing dir_merge()

On Wed, 15 Aug 2001, Brian Pane wrote: > William A. Rowe, Jr. wrote: > > >Here's my take on the dir_merge patch I offered up. Please review for sanity. > > > Thanks! This looks clear and complete to me. > > There's one point at the end where I disagree, though it may be due to > a bad assumptio

Re: [STATUS] (httpd-2.0) Wed Sep 5 23:45:09 EDT 2001

* On 2001-09-09 at 08:45, David Reid <[EMAIL PROTECTED]> excited the electrons to say: > > Shouldn't these go to the new list? Err, yes. Fixed. Thanks! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "A

Re: Apache-1.3: question about mod_unique_id

On Fri, 24 Aug 2001, Günter Knauf wrote: > Hi, I've compiled mod_unique_id for Win32 and for Netware, and on both > platforms it seems to work the same as with Unix, I can see a unique > id with SSI and cgi scripts; so can someone please explain why we have > the #error about not supporting multi

Re: chunking of content in mod_include?

On Mon, 10 Sep 2001, dean gaudet wrote: > > I don't care if mod_include buffers 200 Megs, as long as it is > > constantly doing something with the data. If we have a 200 Meg file > > that has no SSI tags in it, but we can get all 200 Meg at one time, > > then we shouldn't have any problem just s

Re: merge macros

On Mon, Sep 10, 2001 at 03:18:35PM -0700, Ryan Bloom wrote: > On Monday 10 September 2001 15:11, Sander Striker wrote: > > Ryan, was that a -1, or just a 'don't invest time in it, I don't > > think it's worth it'? > > The latter. I would never veto something like this, I just don't believe that

[PATCH 3] performance patch for mod_log_config

Here's an updated version of the patch that fixes the race condition that Dean pointed out involving requests that last almost exactly 15 seconds. The comments in the code describe the "snapshot" technique that it uses to detect and correct the race condition. --Brian Index: modules/loggers/mod

Re: chunking of content in mod_include?

On Mon, 27 Aug 2001, Ryan Bloom wrote: > I don't care if mod_include buffers 200 Megs, as long as it is constantly doing > something with the data. If we have a 200 Meg file that has no SSI tags in > it, but we can get all 200 Meg at one time, then we shouldn't have any problem > just scanning t

[Fwd: video/vnd.mpegurl at ftp.isi.edu and default mime.types file.]

Roundabout, rather. I am not sure what his point is, but FWIW. Original Message Subject: RE: [Fwd: video/vnd.mpegurl at ftp.isi.edu and default mime.types file.] Date: Mon, 10 Sep 2001 13:58:52 -0700 From: "Heiko Recktenwald" <[EMAIL PROTECTED]> Reply-To: "Heiko Recktenwald" <[

Re: [PATCH 2] Re: [PATCH] performance patch for mod_log_config

dean gaudet wrote: [...] >but still, does this really work? 'cause the time used is >r->request_time, if a request takes longer than 14 seconds or so to >generate/serve then the logger is going to be asking for timestamps which >are dangerously close to your cache rollover. and since you can'

Dr. Mark Adler on ZLIB patent issues

Hello all. This is Kevin Kiley As promised... Below is a cut from the second conversation I had with Dr. Mark Adler ( co-author of ZLIB ) this weekend regarding some of the possible legal 'patent' issues that have been raised ( Ryan, Dirk, others? ) as they might relate to using ZLIB inside

Re: [PATCH] worker MPM: reuse transaction pools

On Mon, Sep 10, 2001 at 03:13:48PM -0700, Brian Pane wrote: > I suppose there are a total of four candidate designs, right? It looks > like you're varying two independent dimensions: > * condition variable strategy: one CV, or one per thread > * pool strategy: worker-managed, or listener-mana

Re: merge macros (was: Re: mod_ssl broken)

On Monday 10 September 2001 15:11, Sander Striker wrote: > Ryan, was that a -1, or just a 'don't invest time in it, I don't > think it's worth it'? The latter. I would never veto something like this, I just don't believe that it is required. Ryan __

Re: [PATCH] worker MPM: reuse transaction pools

Aaron Bannert wrote: [...] >1) "short and sweet" > > - single listener > - creates a new transaction pool > - uses that pool for the next accept() > - push()es the newly accepted socket and pool on the fd_queue > > - multiple workers > - waiting in pop() on the fd_queue > - performs pr

RE: merge macros (was: Re: mod_ssl broken)

> From: Greg Stein [mailto:[EMAIL PROTECTED]] > Sent: 10 September 2001 22:08 > On Mon, Sep 10, 2001 at 09:23:59AM -0500, William A. Rowe, Jr. wrote: > > From: "Ryan Bloom" <[EMAIL PROTECTED]> > > Sent: Monday, September 10, 2001 8:39 AM > > > > > > I don't mind putting a patch together that does

Re: [PATCH 2] Re: [PATCH] performance patch for mod_log_config

On Mon, 10 Sep 2001, Brian Pane wrote: > dean gaudet wrote: > > > why is there a need for 15 entries? if it's a multiprocess server then > > there's only a need for 1 or 2 entries. if it's a multithreaded server > > then you need to lock the cache (which you're not doing :) > > The whole point

Re: [PATCH] worker MPM: reuse transaction pools

The patch in question was nothing more than an attempt to further improve worker, and was perhaps a little premature. I have, however, spent some time developing two possible alternative implementations of the worker MPM in addition to what is currently in CVS (which means that I don't expect what

Re: [PATCH 2] Re: [PATCH] performance patch for mod_log_config

dean gaudet wrote: > why is there a need for 15 entries? if it's a multiprocess server then > there's only a need for 1 or 2 entries. if it's a multithreaded server > then you need to lock the cache (which you're not doing :) The whole point of the design is to do the multithreaded cache with

Re: [PATCH] worker MPM: reuse transaction pools

On Tue, 28 Aug 2001, Ryan Bloom wrote: > Creating a pool requires locking a mutex. The more we scale, the worse we > perform. a mutex is not a requirement... as i explained several months ago. (and as greg mentioned, this patch just moves the mutex to the queue from the pool code, which makes

Re: [PATCH] worker MPM: reuse transaction pools

this is the wrong way to fix this problem. i can't imagine any reason why creating a pool should be slow -- rather than band-aid around it, i think it'd be better to find out that problem first. it should be as simple as a couple pointer operations. freelists are a feature of modern memory allo

why serialisation is required with multiple sockets

On Thu, 30 Aug 2001, Dirk-Willem van Gulik wrote: > > On Wed, 29 Aug 2001, Marc Slemko wrote: > > > There is nothing to test. Using the 1.3 process based model, you need > > serialized accepts if you have multiple listening sockets. Period. > > Unless your kernel socket or higher level accept f

merge macros (was: Re: mod_ssl broken)

On Mon, Sep 10, 2001 at 09:23:59AM -0500, William A. Rowe, Jr. wrote: > From: "Ryan Bloom" <[EMAIL PROTECTED]> > Sent: Monday, September 10, 2001 8:39 AM > > > > I don't mind putting a patch together that does this (and to use > > > it in all core modules). I would appreciate suggestions for the

httpd-extras (was: Re: cvs commit: httpd-2.0 STATUS)

On Mon, Sep 10, 2001 at 04:51:41PM +0200, Graham Leggett wrote: > "William A. Rowe, Jr." wrote: > > > http://modules.apache.org/ > > > > Perhaps this isn't frequently referenced enough from our own pages??? > > There is currently no way to distinguish between apache-supported (but > not include

Re: cvs commit: httpd-2.0 STATUS

I'm with Joshua. I don't see the need/purpose for creating a second mechanism for aliasing locations to filesystem paths. Why have two? Why have to answer "which should I use?" etc etc Cheers, -g On Mon, Sep 10, 2001 at 11:48:57AM -0400, Joshua Slive wrote: > > > +* Allow the DocumentRoot

Re: cvs commit: httpd-2.0 STATUS

On Mon, Sep 10, 2001 at 11:39:28AM -0400, Rodent of Unusual Size wrote: > * On 2001-09-10 at 11:17, > Ryan Bloom <[EMAIL PROTECTED]> excited the electrons to say: > > > > We've been over this too much for me to explain again why the module > > doesn't belong in the core. > > In *your* opinion.

Re: cvs commit: httpd-2.0 STATUS

On Mon, Sep 10, 2001 at 11:37:20AM -0400, Rodent of Unusual Size wrote: > * On 2001-09-10 at 11:17, > Jim Jagielski <[EMAIL PROTECTED]> excited the electrons to say: > > > > I dislike the feeling that 'experimental' is a valid dumping ground > > for modules that we think are cool can can't be b

what about proxy? (was: Re: General Availability release qualities?)

On Sun, Sep 09, 2001 at 02:16:25PM +0200, Graham Leggett wrote: > Justin Erenkrantz wrote: > > > - Resolve the proxy situation. A lot of committers (FirstBill > > comes to mind) would like to see this come back in the core. > > If it is ready and the group consensus is to add it, then let's

Re: [proposal] httpd-extras

On Sun, Sep 09, 2001 at 10:15:31AM -0700, Ian Holsman wrote: > I was thinking. > that instead of creating all these little sub-projects why not create a > 'httpd-extras' one. First, I would suggest that we get the httpd-rollup (or somesuch) working first (I suggested this last week), so that we

Re: cvs commit: httpd-2.0 STATUS

On Mon, Sep 10, 2001 at 11:33:43AM -0400, Rodent of Unusual Size wrote: > * On 2001-09-10 at 11:17, > Ryan Bloom <[EMAIL PROTECTED]> excited the electrons to say: > > > > I have removed my veto. Although, I would point out that illegitimate veto > > or not, nobody in this group has ever gotten

why mod_gz "now" ? (was: Re: cvs commit: httpd-2.0 STATUS)

On Mon, Sep 10, 2001 at 12:26:58PM -0400, [EMAIL PROTECTED] wrote: >... > If everyone really agrees with Justin/Ian and others that the > development tree needs a GZIP filter BEFORE the next > beta and it ( for some reason ) has to become part of the > core *at this moment* then just go with mod_g

Re: [RFC] InodeEtag option

"Dietz, Phil E." wrote: > > If the concensus says "Please don't Extend Options", I will > provide this patch as a directive. Please do, so we can get it into 1.3.21.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Serv

Re: cvs commit: httpd-2.0 STATUS

Ryan Bloom wrote: > I have removed my veto. thanks, I know I carefully reviewed the case you were making before my recent vote change in support of letting it go into experimental. the small kernel, the dominace of GA 2.0 are both powerful arguements. > ... veto ... it's always a pain when

Re: cvs commit: apache-1.3 STATUS

Sander Temme <[EMAIL PROTECTED]> writes: > on 9/10/01 7:46 AM, Jeff Trawick at [EMAIL PROTECTED] wrote: > > > now I see that I get to play with libraries: > > > > Undefined first referenced > > symbol in file > > sqrt

Re: ap_kill_timeout(),ap_hard_time_out() (1.3) = 2.0 ??

> On Monday 10 September 2001 10:11, Farag, Hany M (Hany) wrote: > > No. those functions were useful in 1.3, because we used SIGALRM to > deal with timeouts. In 2.0, we use the timeout that we pass to the I/O > functions to expire a function call. There is no way to cancel those > timeouts. >

Re: ap_kill_timeout(),ap_hard_time_out() (1.3) = 2.0 ??

On Monday 10 September 2001 10:11, Farag, Hany M (Hany) wrote: No. those functions were useful in 1.3, because we used SIGALRM to deal with timeouts. In 2.0, we use the timeout that we pass to the I/O functions to expire a function call. There is no way to cancel those timeouts. Ryan > Hi, >

ap_kill_timeout(),ap_hard_time_out() (1.3) = 2.0 ??

Hi, are there a similar functions to the following in 2.0(ap_kill_timeout(),ap_hard_time_out())? Thanks Hany

RE: cvs commit: httpd-2.0 STATUS

> -Original Message- > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > 2. It encourages people to use where they should be > using . > > (Imagine if you protected this block with basic > auth, but forgot > > that another URL can access the same directory.) > > Wouldn't matter.

Re: cvs commit: httpd-2.0 STATUS

In a message dated 01-09-10 12:28:55 EDT, Kevin Kiley wrote... > The following is NOT flamebait. I swear. > It is just an observation that is missing from the discussion. > > I am just pointing out that no one has done a really good > code review of mod_gz even if the 'consensus' is to drop

Re: cvs commit: httpd-2.0 STATUS

From: "Joshua Slive" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 10:48 AM > > +* Allow the DocumentRoot directive within scopes? This > > + allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed > > + by a to become simply > > + DocumentRoot /some

Re: cvs commit: httpd-2.0 STATUS

In a message dated 01-09-10 10:00:09 EDT, Ryan wrote... > >> All I keep thinking, is that we are trying to spite RC by adding a > different GZ module > > Don't worry about it. Let's see if we can make a decision on what is > good for the survival of Apache irrespective of what that means fo

Re: cvs commit: apache-1.3 STATUS

on 9/10/01 7:46 AM, Jeff Trawick at [EMAIL PROTECTED] wrote: > now I see that I get to play with libraries: > > Undefined first referenced > symbol in file > sqrtab.o > ld: fatal: Symbol referencing errors. No outp

Re: cvs commit: httpd-2.0 STATUS

"William A. Rowe, Jr." wrote: > > > http://modules.apache.org/ > > > > > > Perhaps this isn't frequently referenced enough from our own pages??? > > > > There is currently no way to distinguish between apache-supported (but > > not included in the core) modules, and third party modules which have

RE: cvs commit: httpd-2.0 STATUS

> +* Allow the DocumentRoot directive within scopes? This > + allows the beloved (crusty) Alias /foo/ /somepath/foo/ followed > + by a to become simply > + DocumentRoot /somefile/foo (IMHO a bit more legible > + and in-your-face.) This proposed change would

Re: cvs commit: httpd-2.0 STATUS

* On 2001-09-10 at 11:17, Ryan Bloom <[EMAIL PROTECTED]> excited the electrons to say: > > We've been over this too much for me to explain again why the module > doesn't belong in the core. In *your* opinion. Other people have different but equally valid opinions. No one person sets an absol

Re: cvs commit: httpd-2.0 STATUS

* On 2001-09-10 at 11:17, Jim Jagielski <[EMAIL PROTECTED]> excited the electrons to say: > > I dislike the feeling that 'experimental' is a valid dumping ground > for modules that we think are cool can can't be bothered with. Is that supposed to be 'but can't be bothered with'? If so, that i

Re: cvs commit: httpd-2.0 STATUS

* On 2001-09-10 at 11:17, Ryan Bloom <[EMAIL PROTECTED]> excited the electrons to say: > > I have removed my veto. Although, I would point out that illegitimate veto > or not, nobody in this group has ever gotten away with going through a veto. > The only reason I have removed my veto is that

Anyone willing to test drive...

this patch with suexec and ssi exec cmd/exec cgi? I've essentially folded the standard course of program and argv cleanup into a single default_build_command function, that can be overridden (and will be, by mod_win32), eliminating all the registry command cruft from the core. However, the cod

Re: cvs commit: httpd-2.0 STATUS

From: "Graham Leggett" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 9:51 AM > "William A. Rowe, Jr." wrote: > > > http://modules.apache.org/ > > > > Perhaps this isn't frequently referenced enough from our own pages??? > > There is currently no way to distinguish between apache-suppor

Re: cvs commit: httpd-2.0 STATUS

On Monday 10 September 2001 07:32, Jeff Trawick wrote: > Maybe I shouldn't care, but I don't like these depictions :( > > Ryan Bloom <[EMAIL PROTECTED]> writes: > > On Monday 10 September 2001 03:59, Greg Stein wrote: > > > Some people believe his veto is illegitimate -- that there is no > > > tec

request for some feedback

hi, I have made some changes to the apache 1.3.20 source in order to accomodate for running child processes as different users/groups. I would like to know what people think of what I've done, and hopefully I won't make an ass of myself. The attached zip contains a README which is pretty much ex

Re: cvs commit: httpd-2.0 STATUS

"William A. Rowe, Jr." wrote: > http://modules.apache.org/ > > Perhaps this isn't frequently referenced enough from our own pages??? There is currently no way to distinguish between apache-supported (but not included in the core) modules, and third party modules which have no implied level of c

Re: cvs commit: httpd-2.0 STATUS

From: "Jeff Trawick" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 9:32 AM > Another theory (I know this one to be true for at least one person :) > ) is that some folks were in favor of a GZ module and there was only > one to look at properly and choose from, and it seemed reasonably > c

Re: cvs commit: apache-1.3 STATUS

Jim Jagielski <[EMAIL PROTECTED]> writes: > Try this patch... Works under Solaris 8, Darwin, FreeBSD (3/4) and > A/UX: +1 says "Sun WorkShop 6 update 2 C 5.3 2001/05/15" on Solaris 2.6 Thanks! now I see that I get to play with libraries: Undefined first referenced symb

Re: cvs commit: httpd-2.0 STATUS

From: "Gomez Henri" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 9:05 AM > A clean solution could be to add a page (on site and in distro) > listing all known external modules, functionnalities provided and > of course their home page. http://modules.apache.org/ Perhaps this isn't freq

Re: cvs commit: httpd-2.0 STATUS

Maybe I shouldn't care, but I don't like these depictions :( Ryan Bloom <[EMAIL PROTECTED]> writes: > On Monday 10 September 2001 03:59, Greg Stein wrote: > > Some people believe his veto is illegitimate -- that there is no technical > > reason for vetoing the inclusion into modules/experimental

Re: mod_ssl broken

From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 8:39 AM > > I don't mind putting a patch together that does this (and to use > > it in all core modules). I would appreciate suggestions for the > > final names though (naming isn't my strong side). > > > > AP_CFG_MERGE > >

Re: cvs commit: httpd-2.0 STATUS

"Gomez Henri" <[EMAIL PROTECTED]> wrote: > As a mod_gzip user, I was first happy to see it included in Apache 2.0 > distro, but Ryan got very valid arguments, one being that the core should > be tiny, fast and bug free. > > The argument for having modules included in release is that if > they ar

Re: cvs commit: httpd-2.0 STATUS

>> Some people believe his veto is illegitimate -- that there is no technical >> reason for vetoing the inclusion into modules/experimental. >Ryan wrote: >I have removed my veto. Although, I would point out that illegitimate veto >or not, nobody in this group has ever gotten away with going throu

RE: cvs commit: httpd-2.0 STATUS

>> All I keep thinking, is that we are trying to spite RC by adding a different GZ module Don't worry about it. Let's see if we can make a decision on what is good for the survival of Apache irrespective of what that means for RC. Peter -Original Message- From: Ryan Bloom [mailto:[EMAI

Re: cvs commit: httpd-2.0 STATUS

> > I have removed my veto. Although, I would point out that illegitimate veto > or not, nobody in this group has ever gotten away with going through a veto. > The only reason I have removed my veto is that it really looks like everybody > was about to ignore it anyway. This whole thing just le

Re: cvs commit: httpd-2.0 STATUS

On Monday 10 September 2001 03:59, Greg Stein wrote: > On Fri, Sep 07, 2001 at 10:38:45PM -0700, William A. Rowe, Jr. wrote: > >... > > Ryan's veto has effectively tabled this for now. I'm begining to respect > > this from the perspective of putting a release in peoples hands. It can > > be intr

Re: mod_ssl broken

On Monday 10 September 2001 06:28, Sander Striker wrote: > [dropped dev@subversion] > > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > > Sent: 10 September 2001 14:37 > > From: "Sander Striker" <[EMAIL PROTECTED]> > > Sent: Monday, September 10, 2001 3:24 AM > > > > > >> I've looked int

Re: cvs commit: apache-1.3 STATUS

[EMAIL PROTECTED] wrote: > > trawick 01/09/10 05:34:50 > > Modified:.STATUS > Log: > 1.3 won't compile with Sun WorkShop. > > My feelings certainly won't be hurt if somebody else jumps in :) I > need to get some other stuff off my plate before looking into this. >

Re: [PATCH 2] Re: [PATCH] performance patch for mod_log_config

On Sunday 09 September 2001 23:51, Brian Pane wrote: > Cliff Woolley wrote: > >On Sun, 9 Sep 2001, Brian Pane wrote: > >>I think putting it in APR would work. The one limitation I can think of > >>is that adding the cache in apr_explode_localtime() itself wouldn't be a > >>win because we'd have t

Re: mod_imap

On Sunday 09 September 2001 22:16, Brian Pane wrote: > Cliff Woolley wrote: > >Does anyone else think that mod_imap is at this point in time a rather > >unfortunate name for an image-map handling module? > > I agree. mod_imagemap, maybe? Or we could just remove it since even Randy (the original

RE: mod_ssl broken

[dropped dev@subversion] > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > Sent: 10 September 2001 14:37 > From: "Sander Striker" <[EMAIL PROTECTED]> > Sent: Monday, September 10, 2001 3:24 AM > > > > >> I've looked into this slightly, and the underlying problem is that > > >> ap_merge_

Re: cvs commit: apache-1.3 STATUS

SAFE_MUTEX results in a dual-level macro expansion... the first for accept_mutex_child_init (which needs to check for a NULL pointer before calling) and then the handling of single listen. I'm wondering if it's actually in the accept_mutex_child_init phase where it dies. I'll look... [EMAIL PRO

Re: mod_ssl broken

From: "Sander Striker" <[EMAIL PROTECTED]> Sent: Monday, September 10, 2001 3:24 AM > >> I've looked into this slightly, and the underlying problem is that > >> ap_merge_per_dir_configs finds a previous cached merge (for /?) and > >> tries to use it but the entry for mod_ssl is NULL. The URL, bt

Re: [PATCH] performance patch for mod_log_config

Brian Pane wrote: > William A. Rowe, Jr. wrote: > >> Is this the right place to be caching, or should this become a >> straightforward >> optimization to apr's time.c functions? I'd think the advantages are >> many for >> keeping 15 current seconds in apr, and would pay off across the >> boar

Re: [PATCH] Enhancement to mod_auth

"William A. Rowe, Jr." wrote: > > It is as secure as any other _Apache_ authn/authz > configuration, I suppose. It needs to be clear that > it is _not_ as secure as os kernel authn/authz. > > This is pretty obvious to us, but might not be so > obvious to some admins. Because we are tying the >

Re: cvs commit: httpd-2.0 STATUS

On Fri, Sep 07, 2001 at 10:38:45PM -0700, William A. Rowe, Jr. wrote: >... > Ryan's veto has effectively tabled this for now. I'm begining to respect > this from the perspective of putting a release in peoples hands. It can > be introduced soon afterwards, or if someone likes, a subproject can b

Re: access subdirectories

Um, what was this in aid of, Brandon? Brandon Caudle wrote: > > -BEGIN PGP MESSAGE- > Version: PGPfreeware 7.0.3 for non-commercial use > > qANQR1DBwU4DxZQfNUjc/gQQB/9b5mfOZP4t/i1uhmyH4m6OajLFZIok/rY7Hrpt > STMPRwwhhqmMpmyEoMJder27nks+aatoYwWPifdj9pVIngI025c0SrfPfCq

Re: [PATCH 2] Re: [PATCH] performance patch for mod_log_config

why is there a need for 15 entries? if it's a multiprocess server then there's only a need for 1 or 2 entries. if it's a multithreaded server then you need to lock the cache (which you're not doing :) isn't the real win in eliminating both the divisions required by the explode time functions an

RE: Authentication and Authorization

> From: sterling [mailto:[EMAIL PROTECTED]] > Hi - > > IMHO, there is no apache dependency that requires auth and authz to be in > the same module usually, it is just logical that the application > handle both phases - but that is on the module writer. Yes, but the choice of doing group looku

RE: mod_ssl broken

> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > From: "Ben Laurie" <[EMAIL PROTECTED]> > Sent: Sunday, September 09, 2001 3:50 PM >> Sander Striker wrote: [...] >>> The problem is that basev == NULL, which causes >>> apr_array_append to barf. >>> I'll be looking into this next week (or