Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Geoffrey Young
sub vhost_socket { -my $module = shift; +my ($module, $nossl) = @_; local $Apache::TestRequest::Module = $module if $module; my $hostport = hostport(Apache::Test::config()); @@ -224,7 +224,7 @@ my($host, $port) = split ':', $hostport; my(%args) = (PeerAddr

Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 09:05:47AM -0500, Geoffrey Young wrote: sub vhost_socket { ... that all looks reasonable. Thanks for the review Geoff! ... that the appropriate status code is returned seems like a valid test that we would want to keep around. maybe keep this but issue another

Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 09:54:26AM -0500, Geoffrey Young wrote: I should have explained this... the issue is that in response to an HTTP request on an SSL port, mod_ssl in 2.0 issues an HTTP/0.9 response, i.e. it just spits out the response body without headers. This makes

Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Geoffrey Young
Well, it gets my vote. If it were to be an argument, it would have to be stripped out of @_ before being passed through to LWP, which sounds like it could get messy. ok, give this a whirl and see if it works for you. --Geoff Index: Apache-Test/lib/Apache/TestRequest.pm

Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 10:40:51AM -0500, Geoffrey Young wrote: Well, it gets my vote. If it were to be an argument, it would have to be stripped out of @_ before being passed through to LWP, which sounds like it could get messy. ok, give this a whirl and see if it works for you. Yup,

Re: [PATCH] vhost_socket tweak

2004-02-18 Thread Geoffrey Young
Joe Orton wrote: On Wed, Feb 18, 2004 at 10:40:51AM -0500, Geoffrey Young wrote: Well, it gets my vote. If it were to be an argument, it would have to be stripped out of @_ before being passed through to LWP, which sounds like it could get messy. ok, give this a whirl and see if it works

port conflicts issue

2004-02-18 Thread Joe Orton
Has anyone else seen this? I regularly manage to get my httpd-test checkout into a state where the config suddenly has conflicting Listen statements (when it didn't on the previous ./t/TEST invocation): $ grep -r --include \*.conf Listen.*:8530 t/conf t/conf/ssl/ssl.conf:Listen

Re: port conflicts issue

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 01:59:31PM -0800, Stas Bekman wrote: Joe Orton wrote: Has anyone else seen this? I regularly manage to get my httpd-test checkout into a state where the config suddenly has conflicting Listen statements (when it didn't on the previous ./t/TEST invocation): $ grep -r

Re: apr/apr-util python dependence

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote: requiring automake is not something I personally would be excited about... I'd like to see how bad a conversion to ordinary sh would turn out.. also, I'd guess that a conversion to the less cool but more widely

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
The subject is whether Python can be required for running buildconf, not for running configure make. I don't see a problem requiring Python for buildconf. The problem with python is that it is an exotic language and hardly installed anywhere (not everyone runs Linux). Just

Re: apr/apr-util python dependence

2004-02-18 Thread Greg Stein
On Wed, Feb 18, 2004 at 10:13:51AM +, Joe Orton wrote: On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote: requiring automake is not something I personally would be excited about... I'd I'd -1 it right off the bat. No way on automake. like to see how bad a conversion to

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
Automake is clearly not a choice, nor has it ever been for a project of considerable size. And recursive make clearly sucks -- the PHP project got rid of it 2 years ago. We agree on these points. It was also written in Python because it is *just* starting. That script will

Re: interface of the 2.1 authentication framework / behaviour of mod_digest/mod_basic

2004-02-18 Thread Axel Grossklaus
André Malo wrote: moin, I'd guess there's question what do you want to change when. In digest authentication the username is an integral part of the hashed data, so you cannot change it during the authentication stage. Does that change anything in your proposal? not really. i know that

Re: [PATCH] OpenSSL dynamic engines under 2.0.48

2004-02-18 Thread Serge E. Hallyn
Jeff Trawick [EMAIL PROTECTED] wrote: why not SSLCryptoDevice ibmca /usr/local/lib/hw_ibmca.so for dynamically loaded crypto devices? That's nice and clean. I can put up a new patch to do this. Alternatively, I could resubmit Geoof Thorpe's SSLCryptoDeviceCtrl patch. This would make

Time for 1.3.30??

2004-02-18 Thread Jim Jagielski
I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|]

Re: Time for 1.3.30??

2004-02-18 Thread Bill Stoddard
Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. +1 Bill

Re: apr/apr-util python dependence

2004-02-18 Thread Brian W. Fitzpatrick
On Wed, 2004-02-18 at 05:13, Sascha Schumann wrote: Automake is clearly not a choice, nor has it ever been for a project of considerable size. And recursive make clearly sucks -- the PHP project got rid of it 2 years ago. We agree on these points. +1 It was also written

Re: Add Exception Hooks to 2.0

2004-02-18 Thread Mads Toftum
On Thu, Feb 12, 2004 at 06:39:43AM -0500, Jeff Trawick wrote: It applies and builds cleanly for me with HEAD of APACHE_2_0_BRANCH but I have not had time to test as of yet. Once I can do so, I'll add a vote to the STATUS file. If you do try it out, post your results ;) Tested on linux

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
As part of the configure process, I would agree with you, but as part of buildconf, I disagree--not everyone needs to run buildconf--only developers, and if you're a developer, it's *really* not asking that much to have Python on your dev box. That must be a wonderful world where you run

Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Sander Striker
On Wed, 2004-02-18 at 15:28, Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. In response to this, how do we feel about doing 2.0.49 aswell? Sander

Re: Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Jim Jagielski
We have a showstopper, don't we? On Feb 18, 2004, at 12:34 PM, Sander Striker wrote: On Wed, 2004-02-18 at 15:28, Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL

Re: [Patch] ap_soak_end_container and argument-less Block directives

2004-02-18 Thread Geoffrey Young
Philippe M. Chiasson wrote: As can be seen with this simple config file: IfDefine not-defined Location /Location /IfDefine $ httpd -f broken.conf Syntax error on line 1 of broken.conf: Expected /Location but saw /Location ok, I tested your patch against the perl-framework and ran a

Re: [PATCH] OpenSSL dynamic engines under 2.0.48

2004-02-18 Thread Jeff Trawick
Serge E. Hallyn wrote: Jeff Trawick [EMAIL PROTECTED] wrote: why not SSLCryptoDevice ibmca /usr/local/lib/hw_ibmca.so for dynamically loaded crypto devices? That's nice and clean. I can put up a new patch to do this. Alternatively, I could resubmit Geoof Thorpe's SSLCryptoDeviceCtrl patch.

Re: Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Cliff Woolley
On Wed, 18 Feb 2004, Sander Striker wrote: In response to this, how do we feel about doing 2.0.49 aswell? +1, but let's make sure to get the mod_usertrack fix finally committed. Jim already committed it to 1.3.x as far as I know, and there's no reason not to commit it to 2.0.x and 2.1.x except

RE: Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Manni Wood
Ummm... as the person who created the new bug (by successfully stomping a years-old one in the same module), I have a particular interest in the solution of this bug. I had submitted a patch to the 2.x series on bugzilla, and, eventually, things died down with no direction, so I waited for

Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Brad Nicholes
+1 Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, February 18, 2004 10:34:44 AM On Wed, 2004-02-18 at 15:28, Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30

Re: [apreq2] proper support for ithreads

2004-02-18 Thread Beau E. Cox
TO RECAP: On Monday 16 February 2004 10:39 am, you wrote: Beau E. Cox wrote: [...] Yep, the project I did - HTML::Mason:::ApacheHandler2 - on CPAN at http://search.cpan.org/~beau/HTML-Mason-ApacheHandler2-0.01/ is ALL mp2; that's where I had the attemping to free ... scalar ...

RE: Time for 2.0.49, WAS: Re: Time for 1.3.30??

2004-02-18 Thread Manni Wood
Jim, Now I understand. Thanks to you and Cliff for helping stomp this bug! -Manni -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Re: Time for 2.0.49, WAS: Re: Time for 1.3.30?? Manni, What I

Re: License 2.0

2004-02-18 Thread Sander Striker
On Wed, 2004-02-04 at 19:41, André Malo wrote: Anyone already working on switching to it? I'm starting now with the code. Please speak up, if there's already work done. We need to take care of mod_mbox and mod_pop3 aswell. Any takers? ;) Sander

Re: [apreq2] proper support for ithreads

2004-02-18 Thread Stas Bekman
Beau E. Cox wrote: [...] Now the make works. I intalled http-apreq2-cvs (as of 1 hour ago) and cranked up my server with perl 5.8.2. Alas, I receive the same series of errors I received before moving to perl 5.8.3, such as: Attempt to free unreferenced scalar: SV 0x40601238 at

Re: [apreq2] proper support for ithreads

2004-02-18 Thread Beau E. Cox
On Wednesday 18 February 2004 11:23 am, Stas Bekman wrote: Beau E. Cox wrote: [...] Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. [...] OK, I thought DBI has resolved this issue, but apparently it's still

Re: [apreq2] proper support for ithreads

2004-02-18 Thread Stas Bekman
Beau E. Cox wrote: [...] OK, but I also got: Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/HTML/Mason/Request.pm line 160. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/HTML/Mason/Request.pm line 161. And these

Re: License 2.0

2004-02-18 Thread Justin Erenkrantz
--On Wednesday, February 18, 2004 9:55 PM +0100 Sander Striker [EMAIL PROTECTED] wrote: We need to take care of mod_mbox and mod_pop3 aswell. Any takers? ;) Personally, I think that if we ever 'officially' release those modules, we can relicense them at that time. -- justin

Re: License 2.0

2004-02-18 Thread Greg Stein
On Wed, Feb 18, 2004 at 02:03:01PM -0800, Justin Erenkrantz wrote: --On Wednesday, February 18, 2004 9:55 PM +0100 Sander Striker [EMAIL PROTECTED] wrote: We need to take care of mod_mbox and mod_pop3 aswell. Any takers? ;) Personally, I think that if we ever 'officially' release those

Re: [apreq2] proper support for ithreads

2004-02-18 Thread Beau E. Cox
On Wednesday 18 February 2004 11:54 am, Stas Bekman wrote: Beau E. Cox wrote: [...] OK, but I also got: Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/HTML/Mason/Request.pm line 160. Attempt to free unreferenced scalar: SV 0x40601238 at

Re: Time for 1.3.30??

2004-02-18 Thread Ben Laurie
Jeff Trawick wrote: Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. one question: who would support putting the 1.3 versions of mod_backtrace and

Re: Time for 1.3.30??

2004-02-18 Thread Henning Brauer
* Jim Jagielski [EMAIL PROTECTED] [2004-02-18 15:45]: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. I have hughe problems with the new license. What exactly is the point of

Re: Time for 1.3.30??

2004-02-18 Thread Ben Hyde
On Feb 18, 2004, at 6:57 PM, Henning Brauer wrote: I have hughe problems with the new license. Sorry to hear that; a large number of people both inside and outside of the foundation worked very hard on the new license. Some of us are convinced that is a substantial improvement. What exactly is

Changing rec status field in output filter chain

2004-02-18 Thread Jean-Jacques Clar
I am Inside the conditional filter in mod_cache, output filter type = AP_FTYPE_CONTENT_SET-2 (18), and the r-status field is currently a 304. I would like to change it to a 200, but it looks like the status field was already stuffed in the rec-headers_out table, or is it somewhere else? Is

Re: Add Exception Hooks to 2.0

2004-02-18 Thread Jeff Trawick
Mads Toftum wrote: On Thu, Feb 12, 2004 at 06:39:43AM -0500, Jeff Trawick wrote: It applies and builds cleanly for me with HEAD of APACHE_2_0_BRANCH but I have not had time to test as of yet. Once I can do so, I'll add a vote to the STATUS file. If you do try it out, post your results ;)

[STATUS] (apache-1.3) Wed Feb 18 23:45:11 EST 2004

2004-02-18 Thread Rodent of Unusual Size
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/02/18 15:00:46 $] Release: 1.3.30-dev: In development. Jim proposes a release around the start of March, 2004. 1.3.29: Tagged October 24, 2003. Announced Oct 29, 2003.

[STATUS] (httpd-2.1) Wed Feb 18 23:45:19 EST 2004

2004-02-18 Thread Rodent of Unusual Size
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/01/04 15:08:00 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.0 : in development Please consult the following STATUS files for information on related