Re: Problem and Solution to svn import

On Mon, 13 Jan 2003, Aaron Bannert wrote: > > On Monday, January 13, 2003, at 02:40 AM, Greg Stein wrote: > >> 2) I got this even if I put /foobar/ in my request. I haven't done > >> enough research to determine if my shell or the svn client was > >> stripping > >> off the trailing slash, but

Re: Problem and Solution to svn import

On Mon, 13 Jan 2003, Greg Stein wrote: > On Sun, Jan 12, 2003 at 07:31:56PM -0800, [EMAIL PROTECTED] wrote: > > The solution, luckily, is simple. Add the following to your Apache config > > file: > > > > BrowserMatch "SVN" redirect-carefully > > No way. Lines like that are to handle brok

Problem and Solution to svn import

I had a brief conversation with some people on IRC tonight because my svn import was failing. The error was: subversion/libsvn_ra_dav/util.c:358: (apr_err=175002) svn: RA layer request failed svn: OPTIONS request failed on /foobar subversion/libsvn_ra_dav/util.c:343: (apr_err=175002) svn: The OP

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

> > What > > you've done is said "The brigade may not live long enough", but you > > haven't explained how that is the case. > > This, too, is something that we've discussed already. Request > cleanups can happen asynchronously relative to transmission of > brigades created from the request. H

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 21 Dec 2002, Brian Pane wrote: > On Sat, 2002-12-21 at 07:58, [EMAIL PROTECTED] wrote: > > > I'm really sorry, but I am sick of hearing this isn't a solution for apps > > in general. This is now the fourth time that I have asked for a clear > > description of _why_. I helped to design and w

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 22:03, Cliff Woolley wrote: > > > Can we at least agree to do one thing: > > release 2.0.44 *without* Brian's change. > > Okay with me. I am vetoing this change until I get a clear description of the problem it is solving. I have explaine

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 21:37, [EMAIL PROTECTED] wrote: > > On 20 Dec 2002, Brian Pane wrote: > > > > > On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: > > > > > > > > Basically, if you received a brigade from a higher filter, you can only > > > > > assume t

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On Sat, 21 Dec 2002, Cliff Woolley wrote: > On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote: > > > apr_brigade_create(bb, ...); > > fill_brigade_with_data(bb, ...); > > ap_pass_brigade(bb, ...) > > > > ap_clean_brigade(bb, ...); > > fill_brigade_with_more_data(bb, ...); > > ap_pass_brigade(bb, ...); >

Re: [PATCH] Update to Brian's patch to allocate brigades out ofthe bucket allocator

On Fri, 20 Dec 2002, William A. Rowe, Jr. wrote: > At 08:33 PM 12/20/2002, Brian Pane wrote: > >On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: > > > >> > Basically, if you received a brigade from a higher filter, you can only > >> > assume that it will survive a single trip down the filter

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: > > > > Basically, if you received a brigade from a higher filter, you can only > > > assume that it will survive a single trip down the filter stack. > > Right. And you also can't assume that the context th

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On Fri, 20 Dec 2002, Aaron Bannert wrote: > On Friday, December 20, 2002, at 01:26 PM, <[EMAIL PROTECTED]> wrote: > > The pools are used so that we don't > > have to track resources this closely, that is, in fact, their main > > benefit. > > They were also added for performance reasons, but I don

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote: > On 20 Dec 2002, Brian Pane wrote: > > > On Fri, 2002-12-20 at 08:57, [EMAIL PROTECTED] wrote: > > > I am actually pretty sure that allocating brigades out of the > > > bucket_allocator is a VERY big mistake. In fact, I am close to asking > > > that c

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 12:19, [EMAIL PROTECTED] wrote: > > > As for this not working when the filter and handler are in different > > threads, of course it will. As long as the buckets are copied into a > > brigade that was allocated out of a pool that will sti

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 11:24, [EMAIL PROTECTED] wrote: > > > U, I don't believe that it is possible for a brigade to outlive the > > transaction that created it, especially not when you look at how brigades > > are used in the web server. > > Sure it can. A

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

> and you will have a hell of a time tracking it down. I can gaurantee that > this change caused a memory leak. I know it did because Greg Stein and I > argued over leaving a comment in the code that said essentially "This > would be a memory leak if the brigade were allocated out of a pool, but

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

On 20 Dec 2002, Brian Pane wrote: > On Fri, 2002-12-20 at 08:57, [EMAIL PROTECTED] wrote: > > I am actually pretty sure that allocating brigades out of the > > bucket_allocator is a VERY big mistake. In fact, I am close to asking > > that change to be backed out because it is too dangerous. > > >

Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator

I am actually pretty sure that allocating brigades out of the bucket_allocator is a VERY big mistake. In fact, I am close to asking that change to be backed out because it is too dangerous. When we first designed buckets and bucket brigades, we made one VERY clear distinction. Bucket_brigades

[PATCH] new include in mod_include.h

mod_include.h requires util_filter.h, but it doesn't include it. This is fine for Apache itself, because everywhere that mod_include is used, util_filter is already included. However, for people extending mod_include, this means that they must include util_filter. Here is a patch to fix it. In

Re: [patch] perchild MPM bug fixes (+ open problem)

On Mon, 21 Oct 2002, Johannes Erdfelt wrote: > On Mon, Oct 21, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > What I was thinking was to add an artificial limitation that you can't > > > > > share an IP:port pair across two different uid/gid's since that's the > > > > > only case you

Re: [patch] perchild MPM bug fixes (+ open problem)

solution to this, is to have the child > > processes close the sockets for any requests that they cannot > > handle. This will also improve the chance that a request won't be passed > > if you have vhosts with different ports. Consider the follow

Re: [patch] perchild MPM bug fixes (+ open problem)

On Thu, 17 Oct 2002, Johannes Erdfelt wrote: > Ryan, I've CC'd you on this just to let you see the patch. If you don't > want me to involve you in this, please accept my apologies and let me > know and I won't CC you in any further patches. I have no problem being CC'ed on patches, although for t

Re: [patch] perchild MPM bug fixes (+ open problem)

> > Consider the case where an admin configures the server to listen on > > www.foo.com:8080, but he never assigns a child process to listen to that > > port. If you just don't accept the connections, the user will hang > > forever. If every child process, however, actively closes the sockets >

Re: Final patch for a long time.

On Tue, 15 Oct 2002, Johannes Erdfelt wrote: > On Tue, Oct 15, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > The first project is the Perchild MPM. It basically works, but there are > > bugs. The module works for simple cases. However, I have seen a couple of bugs: 1) The second r

Final patch for a long time.

The recent conversations on this list have made me finally realize that I have been here too long. I need a project that is not the Apache web server. So, this is my good-bye. I will be unsubscribing from the Apache web server development lists in the next day or two. I will still be involved

Re: Auth: Start the httpd-2.1 branch finally?

On Sun, 13 Oct 2002, Justin Erenkrantz wrote: > --On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive > <[EMAIL PROTECTED]> wrote: > > > One more note: I'd like to see the rename of mod_access reversed. > > That just seems like a gratuitous change that hurts users and > > doesn't really help

Re: Auth: Start the httpd-2.1 branch finally?

On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: > At 03:33 PM 10/13/2002, [EMAIL PROTECTED] wrote: > >On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: > > > >> At 11:40 AM 10/13/2002, Jim Jagielski wrote: > >> >[EMAIL PROTECTED] wrote: > >> >> > >> >> In the message above, I don't > >> >> think

Re: Auth: Start the httpd-2.1 branch finally?

On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: > At 11:40 AM 10/13/2002, Jim Jagielski wrote: > >[EMAIL PROTECTED] wrote: > >> > >> In the message above, I don't > >> think you are advocating a 2.1 branch. It sounds like you believe that > >> we should take the time to finish 2.0 before movin

Re: Auth: Start the httpd-2.1 branch finally?

On Sun, 13 Oct 2002, Greg Stein wrote: > On Sat, Oct 12, 2002 at 06:18:41PM -0400, [EMAIL PROTECTED] wrote: > >... > > I think there is a much easier way to satisfy everybody and stay in the > > 2.0 tree. The problem right now, is that the MMN isn't granular > > enough. All we know, is that we

Re: Auth: Start the httpd-2.1 branch finally?

On Fri, 11 Oct 2002, William A. Rowe, Jr. wrote: > At 11:21 PM 10/11/2002, [EMAIL PROTECTED] wrote: > > >I am so sick of this conversation. 2.0 isn't done yet. It won't be done > >until it is actually stable, and it isn't currently stable. > > Fine. That's no reason to deprecate modules mid-

Re: Auth: Start the httpd-2.1 branch finally?

I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. And yes, this is very harshly worded. We

Re: Auth: Start the httpd-2.1 branch finally?

On Sat, 12 Oct 2002, Justin Erenkrantz wrote: > --On Friday, October 11, 2002 10:00 PM -0700 Brian Pane > <[EMAIL PROTECTED]> wrote: > > > I don't have a strong opinion about the authn redesign, > > but I do have one change in mind that would fit well in > > 2.1: async write support. And async

Re: Auth: Start the httpd-2.1 branch finally?

put their code in the httpd-2.1 branch? They shouldn't. I will personally be doing some pwork in /home/rbb/cvs either on www.apache.org or www.rkbloom.net in the next few weeks. Once I have a working prototype, I will open it up to people to look at and play with. Only then can we decide if

Re: Auth: Start the httpd-2.1 branch finally?

On Sat, 12 Oct 2002, Jim Jagielski wrote: > [EMAIL PROTECTED] wrote: > > > > In all of these cases, there was a developer or three, who created a CVS > > tree either in their home directories, or in the main CVS area. They made > > the major changes that they wanted to see made, and then they a

Re: cvs commit: httpd-2.0/server log.c

On 13 Oct 2002 [EMAIL PROTECTED] wrote: > wrowe 2002/10/12 20:25:04 > > Modified:server log.c > Log: > Some errors are impossible to fathom, without the user knowing certain > base numbers. This patch introduces "(EAP ##): Eap message" for the EAP > errors, "(OS ##):

Re: segfault in mod_negotiation.c

On 12 Oct 2002, Jeff Trawick wrote: > "Gregory (Grisha) Trubetskoy" <[EMAIL PROTECTED]> writes: > > > --- mod_negotiation.c Fri Aug 9 15:21:57 2002 > > +++ mod_negotiation.c.new Sat Oct 12 15:47:36 2002 > > @@ -2881,7 +2881,7 @@ > > int res; > > int j; > > > > -if (r->fin

Re: Auth: Start the httpd-2.1 branch finally?

On Sat, 12 Oct 2002, Glenn wrote: Glenn, thanks I had deleted Jim's message and I was re-creating it. You made it so I didn't have to. :-) > On Sat, Oct 12, 2002 at 05:11:29PM -0400, Jim Jagielski wrote: > > This is going to sound like a grumpy old man talking, but it's sounding > > more and

Re: apache test suite?

look at httpd-test. Ryan On Sat, 12 Oct 2002, David Burry wrote: > Has anyone worked on an Apache test suite? You know, like how many things > have a "make test" that runs all sorts of tests... or perhaps a separate > package that runs tests... I might be interested in starting one but would

Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"

What we are learning here is simple. We need to do the counting in the core_output_filter. If that means adding a field to the conn_rec, or somehow getting the request_rec in the core_output_filter doesn't matter. The count needs to be done in the core_output_filter, by tallying the amount of

Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"

On 12 Oct 2002, Bojan Smojver wrote: > On Fri, 2002-10-11 at 18:58, David Burry wrote: > > > This should also be a concern for anyone who's using mod_logio to charge for > > bandwidth, because customers should be concerned about some serious > > overcharging going on here! > > Only if you charg

Closing bugs.

Please do not mark bugs FIXED unless the problem is actually solved. I have noticed that bugs against experimental modules are often being closed with the explanation that the module isn't really ready for production use yet. That isn't a good reason to close a bug. The bug still exists, but p

Re: sockets and such

On Thu, 10 Oct 2002, Randall Stewart wrote: > [EMAIL PROTECTED] wrote: > > On Thu, 10 Oct 2002, Randall Stewart wrote: > > > > > >>Hi: > >> > >>I am working on getting apache2 (2.0.43) to be able > >>to listen on SCTP sockets as well as TCP. > >> > >>This involves a small amount of work expandi

Re: Apache and Unix domain sockets

uOn Thu, 10 Oct 2002, Bojan Smojver wrote: > This might sound silly, but can one make Apache 2.0 listen to a Unix domain > socket instead of a TCP socket? > > I looked through the code that has to do with sockets and it seemed as if that > was not possible at this point. But I might have missed

Re: sockets and such

On Thu, 10 Oct 2002, Randall Stewart wrote: > Hi: > > I am working on getting apache2 (2.0.43) to be able > to listen on SCTP sockets as well as TCP. > > This involves a small amount of work expanding the > socket_t to have a protocol field. It should be possible to do this without any core ch

Re: SSL Upgrade support.

Joe, I tried to compile cadaver 0.19.1 and 0.18.5, but neither one would compile for me. Do you happen to have linux binaries lying around, or do you have the magic incatation to get it to compile? BTW, I tried 0.18.5 becasue according to the CVS logs, it looks like that is the cadaver version

Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(

On Mon, 7 Oct 2002, Pier Fumagalli wrote: > On 7/10/02 21:45, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > > > At 03:27 PM 10/7/2002, Sander Temme wrote: > >> Your HEAD probably uses the glibtool(ize) installation on your local box, > >> which on 10.2 by default is 1.4.2. The tarball was

SSL Upgrade support.

Just a heads up. I wrote SSL Upgrade support this weekend for Apache 2.0. In my (currently) limited testing, things look pretty good. We currently respond to all requests correctly, and I think I have the SSL filters being inserted properly. However, there are no clients that I know of that s

Re: DO NOT REPLY [Bug 9181] - Unable to set headers on non-2XXresponses.

Please do not close bug reports without entering some kind of information about why it is being closed. Ryan On 4 Oct 2002 [EMAIL PROTECTED] wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT >

Re: cvs commit: httpd-2.0/server core.c

On 1 Oct 2002 [EMAIL PROTECTED] wrote: > gstein 2002/10/01 09:24:41 > > Modified:server core.c > Log: > Fix bug in the default handler. POST is not allowed on regular files. > The resource must be handled by something *other* than the default > handler. -1. This is going t

Re: SSL tests failing.

On Mon, 30 Sep 2002, Justin Erenkrantz wrote: > --On Monday, September 30, 2002 4:43 PM -0400 [EMAIL PROTECTED] wrote: > > > I just tried to make a minor change to the server, and test it to ensure > > that it didn't break anything. Unfortunately, the test suite is currently > > broken with reg

SSL tests failing.

I just tried to make a minor change to the server, and test it to ensure that it didn't break anything. Unfortunately, the test suite is currently broken with regard to SSL. I haven't had time to look into this yet, and probably won't until Tuesday at the earliest. Ryan -- _

Re: POST

On Sun, 29 Sep 2002, Justin Erenkrantz wrote: > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote: > > Because 2.0.42 always displays script source for CGI scripts that use > > POST, I believe that we should put that notice on our main site, and stop > > suggesting 2.0.42 for production

Re: UDP ?

Serving content over UDP does work with 2.0. It takes some work, but all of the required features are there. However, I modified Apache a couple of years ago to serve HTTP over UDP, it doesn't work. The only reason to serve over UDP with Apache, is to serve a different protocol. IF you would

Re: How Do I Create A Per-Worker Pool?

On Wed, 25 Sep 2002, Charles Reitzel wrote: > Thanks for the reply. Forget the worker_rec for the time being. How do > you access the per-thread pool from a module? > > Sorry if I need it spelled out. But I don't see a pointer to it on the > request_rec, the server_rec is process-wide and t

Re: [PATCH] add simple ${ENV} substitution during config file read

On Thu, 26 Sep 2002, Dirk-Willem van Gulik wrote: > > In the department of scratching old itches - any strong objections to me > adding the following patch which allows one to do things like > > # httpd.conf > ServerRoot ${HOME}/apache > Port ${PORT:=80} > ErrorDocument

Re: How Do I Create A Per-Worker Pool?

On Wed, 25 Sep 2002, Ian Holsman wrote: > Leonardo Javier Belén wrote: > > I think I have a question to ask associated to this thread: How can I > > implement a "global pool" of objects. Let me say it better, I want a global > > pool of database connection, first because I have a limited number o

Re: How Do I Create A Per-Worker Pool?

On Wed, 25 Sep 2002, Charles Reitzel wrote: > Hi All, > > This is a thorny (to me) module development question. I have asked on the > module list and searched the archives, but have found only a partial > answer. Any pointers will be appreciated. > > Objective: to create a mutex-free pool p

Re: CGI bucket needed

On Tue, 24 Sep 2002, Greg Stein wrote: > Just ran into an interesting bug, and I've got a proposal for a way to solve > it, too. (no code tho :-) > > If a CGI writes to stderr [more than the pipe's buffer has room for], then > it will block on that write. Meanwhile, when Apache goes to deliver t

Re: instdso.sh - basename confusion

On Tue, 24 Sep 2002, Dirk-Willem van Gulik wrote: > > > > And then try to install (on Solaris) a module as a .so: > > > > > > ../a2/bin/apxs -i -n mod_foo mod_foo.so > > > > I would suggest looking at HEAD rather than 2.0.40 as I made changes > > to instdso.sh to explicitly handle this case.

Re: [PATCH] core_output_filter

On Sat, 21 Sep 2002, Ryan Morgan wrote: > > Thats a good point, I didn't think about that case. Maybe the safe way is > to just add a check for APR_TIMEUP? I would much rather check for EAGAIN than continue to add more codes that could mean failure. Or put more succinctly, there are far more

Re: hep

Done Ryan On Thu, 19 Sep 2002, Jon Travis wrote: > Hep pease unscripe !! > -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -

Re: Seg fault in mod_dav.

On Thu, 19 Sep 2002, William A. Rowe, Jr. wrote: > At 10:05 AM 9/19/2002, [EMAIL PROTECTED] wrote: > >+1 for .42 > > Agreed here, no signs of trouble. > > >And to make it official, .41 should be classified as an alpha release. > > All tarballs rolled are Alpha until otherwise released as Beta

Re: Seg fault in mod_dav.

On Wed, 18 Sep 2002, Justin Erenkrantz wrote: > On Wed, Sep 18, 2002 at 07:47:14PM -0700, Greg Stein wrote: > > Okay... I've checked in the change. I'd suggest tossing 2.0.41 and roll this > > fix into a 2.0.42. (I'm not suggesting using HEAD for 2.0.42) > > > > Something like: > > > > $ cvs ta

Re: Seg fault in mod_dav.

More details. YAY First, a stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 18642)] 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762 1762if ((err = (*vsn_hooks->get_option)(resource, elem, &body)) (gdb) where

Re: [PATCH]: Update request in connection based filters

On 19 Sep 2002, Bojan Smojver wrote: > On Thu, 2002-09-19 at 07:59, [EMAIL PROTECTED] wrote: > > > Great, now one more change. :-) > > > > Don't add the fields to the structure. The conn_Rec has a vector for > > modules to add data to. Create a log_config structure, and add the fields > > th

Seg fault in mod_dav.

I don't know if this is in .41 because I haven't had time to test it yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you send an OPTIONS request for a location that isn't configured for DAV, the module seg faults. I have traced it far enough to know where it is happening, bu

Re: [PATCH]: Update request in connection based filters

On 19 Sep 2002, Bojan Smojver wrote: > On Thu, 2002-09-19 at 00:05, [EMAIL PROTECTED] wrote: > > > The easiest way, would be to put the filters in mod_log_config, and have > > that module save the information in a connection_rec vector. > > OK, I think I roughly understand what is the plan: >

Re: [PATCH]: Update request in connection based filters

On Wed, 18 Sep 2002, Bojan Smojver wrote: > Quoting [EMAIL PROTECTED]: > > > The problem is that the filters aren't HTTP specific. If you make this > > change, then the filters will be written to take advantage of the f->r > > field in connection level filters. Since that field doesn't make se

Re: [PATCH]: Update request in connection based filters

On Wed, 18 Sep 2002, Bojan Smojver wrote: > I understand. But isn't the ap_read_request HTTP specific given it's creating > the request and all? In other words, if protocol is HTTP, we let connection > filter know about the request. If not, we don't. That to me sounds exactly the > same as your s

Re: [PATCH]: Update request in connection based filters

You don't want to do this. A connection based filter is connection oriented. By definition, it has no concept of a request. While this might make sense for HTTP, other protocol modules will have a much harder time with this change. Ryan On 18 Sep 2002, Bojan Smojver wrote: > Justin, > > Af

RE: Tagged and rolled 2.0.41

> > I would also recommend a new tarball with the timestamp tweaked. Something > > like so: > > > > $ tar xzf httpd-tar.gz > > $ touch .../ssl_expr_parse.c > > $ tar czf httpd-tar.gz httpd-... > > > > That's gonna affect the tarball's MD5 signature tho. > > And the PGP signatures. Do

Re: auth stuff still broken

On Tue, 17 Sep 2002, Greg Stein wrote: > On Tue, Sep 17, 2002 at 10:26:02AM -0700, Aaron Bannert wrote: > > On Tue, Sep 17, 2002 at 01:00:44PM -0400, Ryan Bloom wrote: > > > > Does that make any sense? I'm certain you will have users misconfigure > > > > the 'backstop' modules (_default flavors)

Re: auth stuff still broken

On Tue, 17 Sep 2002, William A. Rowe, Jr. wrote: > I was thinking about this. What about -eliminating- the mod_authn_default > and mod_authz_default, merging them into mod_auth, and moving the > directives from mod_auth_basic and mod_auth_digest into the common > mod_auth. > > Mod_auth would fu

Re: mod_custom_log exits too late?

On 17 Sep 2002, Brian Pane wrote: > On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote: > > On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote: > > > I disagree entirely. There's no need to let the API keep changing > > > continuously, especially not for the sake of "correctness." All

Re: perchild under Solaris 8

On Tue, 10 Sep 2002, Jim Jagielski wrote: > At 11:07 AM -0700 9/10/02, Aaron Bannert wrote: > >On Tue, Sep 10, 2002 at 01:07:30PM -0400, Jim Jagielski wrote: > >> If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure > >> process, perchild will compile relatively cleanly unde

Re: cvs commit: httpd-2.0/support htpasswd.c

This message is complete hand-waving. The point of htpasswd is to create password files for mod_auth. It doesn't create password files for use with other authentication schemes. More to the point, if anybody ever uses this option, it will FAIL with mod_auth. That violates the principle of lea

Re: El-Kabong -- HTML Parser

On Tue, 10 Sep 2002, Jim Jagielski wrote: > Can we settle down? A donation of code was being offered, and there was > discussion within the ASF about it, but the status of those discussions > weren't being folded back to the donator. > > Before we veer off on yet another tangent, can we address

Re: cvs commit: httpd-2.0/support htpasswd.c

On Tue, 10 Sep 2002, William A. Rowe, Jr. wrote: > At 01:36 AM 9/10/2002, Justin Erenkrantz wrote: > >On Tue, Sep 10, 2002 at 03:00:51AM -, [EMAIL PROTECTED] wrote: > > > jerenkrantz2002/09/09 20:00:50 > > > > > > Modified:.CHANGES > > >support htpasswd.c >

Re: Is it time to split the APR/HTTPD releases ?

+1, as soon as both APR and APR-util have a release. Ryan On Sun, 8 Sep 2002, Ian Holsman wrote: > APR now has version management. > is it time to stop just tagging the HEAD of the apr/apr-util trees > when we make a release and just use the offically released ones? > ie.. we would bundle apr

Re: Tagged the tree

On Mon, 9 Sep 2002, Chris Taylor wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - - Original Message - > From: "Aaron Bannert" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, September 08, 2002 11:22 PM > Subject: Re: Tagged the tree > > > If there are enoug

Re: Tagged the tree

Generally, we do not create tarballs of tags, because the tags are meant to be used by developers before the release is rolled. The problem with tarballs, is that once they are created, they can be downloaded, and then it is very difficult to determine which version of the tarball a user has. B

Re: Releasing 2.0.41

On Fri, 6 Sep 2002, Dale Ghent wrote: > On Fri, 6 Sep 2002, Greg Stein wrote: > > | On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: > | >... > | > There are a few other little bugs that I'd like to fix so that 2.0.41 > | > holds most folks for a month or few. I have no obj

Re: compatibility with C++ modules

So I haven't really looked into how it works, but have you looked at mod_cplusplus? http://sourceforge.net/projects/modcplusplus/ Ryan On 6 Sep 2002, Jeff Trawick wrote: > At about the same time recently that I was doing horrible, > uncommittable hacks to the build to get Apache 2.0 to suppor

Re: mod_mime on virtual requests?

On Wed, 4 Sep 2002, Justin Erenkrantz wrote: > On Wed, Sep 04, 2002 at 09:45:47AM -0400, [EMAIL PROTECTED] wrote: > > It is run_first because each response can only have a single content-type, > > and the only reason to use that hook is to get the content-type. This is > > also a performance iss

Re: Filters question

On Wed, 4 Sep 2002, Graham Leggett wrote: > Hi all, > > Is it possible to read brigades from two filter stacks simultaneously? Yes and no. The two filter stacks share no data at all, so it is perfectly safe to call ap_get_brigade on both filter stacks. However, we can't poll based on filter s

Re: mod_mime on virtual requests?

On Wed, 4 Sep 2002, Justin Erenkrantz wrote: > Someone recently brought up the fact that they couldn't add a PHP > filter to a SVN-served repository via AddOutputFilter. > > I think this is due to the following issues: > > 1) type_checker is a run_first rather than run_all. > >Any reason w

Re: [VOTE] Location of aaa rewrite

On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: > > On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: > > > > > > On Tue, 3 Sep 2002, Chris Taylor wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA1 > > > > > > > > > > > [ ] Check in aaa rewrite to 2.0. > > > > > > [X] Check in aaa

Re: [VOTE] Location of aaa rewrite

On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: > > On Tue, 3 Sep 2002, Chris Taylor wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > > [ ] Check in aaa rewrite to 2.0. > > > > [X] Check in aaa rewrite to 2.1. > > > > > > My view is that it's important to keep 2.0 stable

Re: [VOTE] Location of aaa rewrite

On Tue, 3 Sep 2002, Chris Taylor wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > [ ] Check in aaa rewrite to 2.0. > > [X] Check in aaa rewrite to 2.1. > > My view is that it's important to keep 2.0 stable to attract new > users, and breaking things all the time won't help :) Can

Re: [VOTE] Location of aaa rewrite

On Tue, 3 Sep 2002, Justin Erenkrantz wrote: > Please vote: > > [X] Check in aaa rewrite to 2.0. > [ ] Check in aaa rewrite to 2.1. Ryan

Re: El-Kabong -- HTML Parser

There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. The APR option is faster, but there is some misgivings about whether it belongs in apr-util. The vote was done, and it seems to be accepted, but Greg was keeping tally, so I don

Re: perchild on Darwin, hmmm

That is awesome! The code is REALLY crufty still, but it would be great to get more eys on it. Fair warning, it is REALLY fragile still. Happy hacking. :-) Ryan On Fri, 30 Aug 2002, Jim Jagielski wrote: > Except for the poll.h header line, perchild compiled quite nicely on > Darwin (Jagu

Re: what's the hubbub? (was: Re: 2.0/2.1 split)

++1. Ryan On Fri, 30 Aug 2002, Jim Jagielski wrote: > Ian Holsman wrote: > > > > what we need most is a stable tree for a couple of months not spliting > > out to a 2.1 tree > > > > ++1 > > -- ___ Ryan Bloom

Re: 2.1 repository?

> [...] > > Look at all of the repositories we created that are still left > > around: > > > > apache-1.2 > > apache-1.3 > > apache-apr > > apache-nspr > > httpd-2.0 > > > > The apache-apr and apache-nspr repositories were fairly short-lived. > > I wasn't around when they were created, so perhaps

Re: authn/authz split

On Fri, 30 Aug 2002, William A. Rowe, Jr. wrote: > At 01:48 AM 8/30/2002, Justin Erenkrantz wrote: > >Since no one had any feedback to the earlier posts about splitting > >the auth modules into authn/authz, I decided to just call it authn > >(old auth) and authz (what Dirk called access). > > > >

Re: El-Kabong -- HTML Parser

On Thu, 29 Aug 2002, Aaron Bannert wrote: > > > Justin and I have both given our thumbs up. The question is now where to put > > > the thing. A few people say APR, and few don't like that. A few say httpd, > > > and a few don't like that. Bleh :-) > > > > I'm 100% comfy with the landing spot bei

Re: Going to 2.1? was Re: authentication rewrite

On Wed, 28 Aug 2002, Aaron Bannert wrote: > On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote: > > branches in CVS are awful (perhaps not so with SVN though). > > I have only heard anecdotal evidence for this, but have actually > used cvs branches on other large and very successf

Is anybody getting CVS commit messages?

I realized earlier today that I haven't been seeing commit messages. Is anybody getting these messages? Ryan -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -

Re: [PROPOSAL] Move AUTH_LDAP to /experimental (was: authenticationrewrite)

I am very much against putting more modules into the standard server. Ryan On Tue, 27 Aug 2002, Brad Nicholes wrote: >Now that 2.0.40 has been released and we are in development of .41 > and the fact that there has been a proposal for re-architecting the AUTH > modules, I would like to pro

Re: Counting bytes_sent in core output_filter Re: [PATCH: Apache2.0] mod_log_config: input/output bytes

On Wed, 21 Aug 2002, Brian Pane wrote: > Bojan Smojver wrote: > > >On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote: > > > > > IMO, the best solution is to move the bytes_sent information to the > conn_rec, and have the protocol module reset it whenever it wants to. For > back

Re: Counting bytes_sent in core output_filter Re: [PATCH: Apache2.0] mod_log_config: input/output bytes

> >Adding the request_rec to the bucket is a bad idea, because currently > >buckets have no concept of Apache internals, and I would prefer that they > >stay that way. > > > > The trick is to not add the request_rec to the bucket: just add a > void* "client_data" field to the bucket, so that apr

  1   2   >