Re: [PATCH] vhost_socket tweak
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 = $host, PeerPort = $port);
-if ($module and $module =~ /ssl/) {
+if (!$nossl and $module and $module =~ /ssl/) {
require Net::SSL;
local $ENV{https_proxy} ||= ; #else uninitialized value in
Net/SSL.pm
return Net::SSL-new(%args, Timeout = UA_TIMEOUT);
that all looks reasonable.
This allows a fix for the ssl/http.t failure which has been around
forever:
well, since I have never tried the SSL tests you're probably in a better
position to judge the validity of the tests than I am. but a few comments
anyway :)
-my $res = GET($rurl);
-ok t_cmp(400,
- $res-code,
- Expected bad request from 'GET $rurl'
-);
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 request to
test your below logic?
-
-ok t_cmp(qr{speaking plain HTTP to an SSL-enabled server port},
- $res-content,
- that error document contains the proper hint
-);
I gather that this is the source of the failure that you mention - that for
some reason $res-content isn't sufficient? just out of curiosity, could
you explain the issue? to me, the process looks equivalent, except that the
prior approach was standard.
oh, and you're invoking mod_dir to get to index.html, instead of asking for
it directly, so you'll probably need protection against users that don't
have mod_dir installed. IIRC someone did report that once.
+my $s = Apache::TestRequest::vhost_socket($ssl_module, 1);
+
+unless ($s) {
+warn cannot connect to $hostport: $!;
+return undef;
+}
you probably want to fail here instead of just returning undef. something
like this might be better
t_debug(could connect to $hostport? , $! ? $! : 'yes');
ok($s);
+while ($s) {
+print # read: $_;
I'd use t_debug here as well :)
+$res = 1 if /speaking plain HTTP to an SSL-enabled server port/;
+}
+
+ok t_cmp(1,
+ $res,
+ expected error document hint from HTTP request on SSL port
+ );
there's no reason you need to use t_cmp to compare 1 to 1. if you wanted,
you could do something like
$res = $1 if /(speaking plain HTTP to an SSL-enabled server port)/;
then use that in the t_cmp, or just drop the t_cmp altogether and just use
ok($res);
since the complete response is already present in debug mode.
anyway, just a few suggestions for what they are worth. kudos for keeping
up with the test suite :)
--Geoff
Re: [PATCH] vhost_socket tweak
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
request to test your below logic?
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
TestRequest.pm:lwp_call() barf.
That mod_ssl bug is not really a regression worth worrying about IMO:
browsers handle the error response just fine, so I was trying to just
detect that it sent the right response body.
Now I think about it maybe a better way to fix this would be to let
lwp_call take an argument to allow it to *not* barf on an HTTP/0.9
response:
if ($1 ne 1.0 $1 ne 1.1) {
$error = response had protocol HTTP/$1 (headers not sent?);
}
But working out how lwp_call even gets *called* via GET gives me
headaches. Can anyone help?
joe
Re: [PATCH] vhost_socket tweak
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 TestRequest.pm:lwp_call() barf. indeed. I've been bitten by that myself when trying to specifically test HTTP/0.9. http://marc.theaimsgroup.com/?l=apache-test-devm=102407609105935w=2 perhaps now is a good time to fix that little bit. Ah ha, neat. Yes, I can work around the ssl.t failure very easily like that. agreed. the stuff I proposed before is just one suggestion, but perhaps you can think up a better idea. 0.9 is probably rare enough that it doesn't warrant a huge interface was my thought. 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. joe
Re: [PATCH] vhost_socket tweak
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
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRequest.pm,v
retrieving revision 1.93
diff -u -r1.93 TestRequest.pm
--- Apache-Test/lib/Apache/TestRequest.pm 28 Nov 2003 18:19:45 -
1.93
+++ Apache-Test/lib/Apache/TestRequest.pm 18 Feb 2004 15:38:45 -
@@ -3,7 +3,10 @@
use strict;
use warnings FATAL = 'all';
-BEGIN { $ENV{PERL_LWP_USE_HTTP_10} = 1; } #default to http/1.0
+BEGIN {
+$ENV{PERL_LWP_USE_HTTP_10} ||= 1; # default to http/1.0
+$ENV{APACHE_TEST_HTTP_09_OK} ||= 0; # make 0.9 an option
+}
use Apache::Test ();
use Apache::TestConfig ();
@@ -438,7 +441,8 @@
$error = response had no protocol (is LWP broken or
something?);
}
if ($1 ne 1.0 $1 ne 1.1) {
-$error = response had protocol HTTP/$1 (headers not sent?);
+$error = response had protocol HTTP/$1 (headers not sent?)
+unless ($1 eq 0.9 $ENV{APACHE_TEST_HTTP_09_OK});
}
}
}
Re: [PATCH] vhost_socket tweak
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, works great.
Re: [PATCH] vhost_socket tweak
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 for you. Yup, works great. ok, committed. I debated a bit on making it an option like redirect_ok, but it seemed overly complex, considering how rarely this will be used. it's also easy enough to toggle the environment switch before and after specific tests. --Geoff
port conflicts issue
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 127.0.0.1:8530 t/conf/ssl/proxyssl.conf:Listen 127.0.0.1:8530 and the server won't start up. A -clean fixes it but it's kind of annoying... haven't managed to work out why. joe
Re: port conflicts issue
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 --include \*.conf Listen.*:8530 t/conf t/conf/ssl/ssl.conf:Listen 127.0.0.1:8530 t/conf/ssl/proxyssl.conf:Listen 127.0.0.1:8530 and the server won't start up. A -clean fixes it but it's kind of annoying... haven't managed to work out why. Yup. I saw that many times. It happes because of the inconsistency in what config files are reparsed. Every time config files are reparsed the ports are reassigned. If some files don't get regenerated they will still have the old port numbers. So what needs to be traced, is why 't/TEST -conf' doesn't pick up ssl config files. t/TEST -trace=debug -conf should be helpful. If you don't figure it out, I'll try to resolve that later. I haven't written the ssl part, so I'll need to first understand how does it work. Since it's not a part of the normal config. I didn't get anywhere tonight, but I worked out a repro case for the issue: ./t/TEST -clean ./t/TEST -start-httpd ./t/TEST -stop-httpd touch t/conf/ssl/* ./t/TEST -start-httpd fails joe
Re: apr/apr-util python dependence
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 ported/precompiled/preinstalled P* scripting language would be a rather quick and would not suffer greatly from uncoolness and would pick up additional people able and/or willing to maintain it ;) Remember that the primary focus of a build system is not ease of maintenance or being written in your preferred scripting language. No - the primary focus is being portable. That is why you don't see build systems written in Perl, PHP or Python. 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. joe
Re: apr/apr-util python dependence
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 requiring it for a buildconf run seems excessive to me. Anyway, I have rewritten Perl scripts to reduce buildconf requirements, doing the same with Python scripts should not be any harder. :-) - Sascha
Re: apr/apr-util python dependence
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 ordinary sh would turn out.. also, I'd guess that a conversion to the less cool but more widely ported/precompiled/preinstalled P* scripting language would be a rather quick and would not suffer greatly from uncoolness and would pick up additional people able and/or willing to maintain it ;) Remember that the primary focus of a build system is not ease of maintenance or being written in your preferred scripting language. No - the primary focus is being portable. That is why you don't see build systems written in Perl, PHP or Python. 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. Exactly. buildconf is used by *developers*, not users. Tarballs won't require Python at all to config and build them. It was also written in Python because it is *just* starting. That script will also product .dsp and .dsw files in the future (the Subversion project generates these files, so I intend to follow that model). For now, it is just starting: it got rid of the recursive make crap. But there is a lot more that it can do. So no... switching to a shell script would not be beneficial, as it would cut off future capabilities. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr/apr-util python dependence
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 also product .dsp and .dsw files in the future (the Subversion project generates these files, so I intend to follow that model). For now, it is just starting: it got rid of the recursive make crap. But there is a lot more that it can do. However I completely disagree that Python (or Perl or PHP) is a good choice for use in build systems. So no... switching to a shell script would not be beneficial, as it would cut off future capabilities. I doubt that. .dsp and .dsw files are just other text files which can easily be created using sh, grep, sed, tr etc. - Sascha
Re: interface of the 2.1 authentication framework / behaviour of mod_digest/mod_basic
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 digest is going to be a bit tricky, but it should be possible to make the changes without breaking digest authentication. i had a rough look over the digest sources and the proposed additional level of indirection, together with some minor modifications to mod_digest, should suffice. i have not made really detailed plans on what needs to be changed how. as i said, the main reason of the first mail was to find out if a) changes to the current interface for authentication modules would be considered at all. b) the proposed extra functionality would be considered useful in the apache code. just to prevent investing a lot of work and then being told yeah, nice patch. unfortunately we will not accept any changes to the authentication interface. of course, i do not expect a definite yes or no at this point. a changes are not completely out of the question and if we like your implementation we will consider adding it would be enough... tty, axel
Re: [PATCH] OpenSSL dynamic engines under 2.0.48
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 the above case uglier, but would be far more powerful, allowing arbitrary control commands to be sent to any openssl engines. Is there a preference? thanks, -serge
Time for 1.3.30??
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] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.30??
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
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 in Python because it is *just* starting. That script will also product .dsp and .dsw files in the future (the Subversion project generates these files, so I intend to follow that model). For now, it is just starting: it got rid of the recursive make crap. But there is a lot more that it can do. However I completely disagree that Python (or Perl or PHP) is a good choice for use in build systems. 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. So no... switching to a shell script would not be beneficial, as it would cut off future capabilities. I doubt that. .dsp and .dsw files are just other text files which can easily be created using sh, grep, sed, tr etc. Ick. Ick ick ick ick ick. Easily is obviously a subjective term. Who wants to write (and, more importantly, *maintain*) hundreds (or thousands) of lines of /bin/sh code? Not to mention the fact that Python can be much more compact than /bin/sh after you hit a certain level of complexity. Anyway, I suppose that agreeing to disagree may be for the best here. Subversion has required python to run autogen.sh for years now, and it's been great for us. -Fitz
Re: Add Exception Hooks to 2.0
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 with prefork and worker - seems to work well. All that seems to be missing are the config directives. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: apr/apr-util python dependence
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 buildconf only on boxes which are under your control all the time. In reality, build system debugging is often required on awkward systems where even a pervasive language such as perl is often unavailable. Ick. Ick ick ick ick ick. Easily is obviously a subjective term. Who wants to write (and, more importantly, *maintain*) hundreds (or thousands) of lines of /bin/sh code? Many people do that all the time. Not to mention the fact that Python can be much more compact than /bin/sh after you hit a certain level of complexity. Build systems don't reach that level. Anyway, I suppose that agreeing to disagree may be for the best here. Agreed. I'll rewrite the .py script on my way tonight and submit it for review. - Sascha
Time for 2.0.49, WAS: Re: Time for 1.3.30??
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??
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 2.0. In response to this, how do we feel about doing 2.0.49 aswell? Sander -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [Patch] ap_soak_end_container and argument-less Block directives
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 few checks against other containers as well (IfModule, etc). everything tested ok so I merged it into 2.1 and proposed for backport to 2.0. nice work philippe :) --Geoff
Re: [PATCH] OpenSSL dynamic engines under 2.0.48
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. This would make the above case uglier, but would be far more powerful, allowing arbitrary control commands to be sent to any openssl engines. Is there a preference? I think you're safe ignoring me, as I didn't know the big picture and was just looking to improve within a limited context.
Re: Time for 2.0.49, WAS: Re: Time for 1.3.30??
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 I just kept forgetting to do so. --Cliff
RE: Time for 2.0.49, WAS: Re: Time for 1.3.30??
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 feedback. So is Jim's patch already ported to 2.x? Is there another forum where this got resolved? Also, in future, should I take more initiative and submit a complete trio of patches instead of waiting for feedback? Helping out is rewarding, but sometimes confusing for newbies like me. Regardless, thanks, all, for helping fix this bug. Cheers, -Manni -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 1:33 PM To: [EMAIL PROTECTED] Subject: Re: Time for 2.0.49, WAS: Re: Time for 1.3.30?? 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 I just kept forgetting to do so. --Cliff
Time for 2.0.49, WAS: Re: Time for 1.3.30??
+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 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: [apreq2] proper support for ithreads
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 ... messages, and why I moved to 5.8.3. Sorry for the delay, Beau. Please try with 5.8.2 and the current cvs of httpd-apreq-2, I've added a proper support for ithreads. Hi Stas: I'm having trouble building httpd-apreq-2 from cvs: 0. perl 5.8.2 reinstalled, apache2 (2.0.48) and mod_perl 2 (latest cvs) made and installed. 1. CVS download OK. 2. Checked that I have all dependencies - OK. 3. ./buildconf - OK 4. perl Makefile.PL --with-apache2-apxs=/usr/apache2/sbin/apxs - OK 5. make - get the following (after it runs a while): [...] cd /bin/sh ./config.status Makefile ./config.status: ./config.status: No such file or directory make: *** [Makefile] Error 127 Looks like a 'cd' to nowhere, then ./config.status can't be found...? The make problem seems to be because $top_builddir is NOT defined. Assuming you are building in the same directory as top_srcdir, as I am, move the 'empty' top_builddir def to the top of the file as: srcdir = . top_srcdir = . top_builddir = . ^ and define it as '.'; the make then works (sorry, I'm weak in the automake department being an ex-M$ weenie :) ), 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 /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. [Wed Feb 18 10:12:34 2004] [notice] caught SIGTERM, shutting down Stas asked me if I could make a 'test' case to display this behaviour; I have not been able to reproduce this problem outside if my apache2/mod_perl 2/mason/etc. server setup yet. Anyway, I now have a test bed that I can fire up on my test server whenever more patches are forthcoming (If you folks need it). Aloha = Beau; -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: Time for 2.0.49, WAS: Re: Time for 1.3.30??
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 did was take the latest/working 2.0.x patch (from the PR report), and backported it to 1.3. I didn't patch the 2.x trees at the same time, because I simply forgot. :/ I believe Cliff is doing that as we speak. On Feb 18, 2004, at 2:33 PM, Manni Wood wrote: 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 feedback. So is Jim's patch already ported to 2.x? Is there another forum where this got resolved? Also, in future, should I take more initiative and submit a complete trio of patches instead of waiting for feedback? Helping out is rewarding, but sometimes confusing for newbies like me. Regardless, thanks, all, for helping fix this bug. Cheers, -Manni -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 18, 2004 1:33 PM To: [EMAIL PROTECTED] Subject: Re: Time for 2.0.49, WAS: Re: Time for 1.3.30?? 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 I just kept forgetting to do so. --Cliff -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: License 2.0
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
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 /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. Attempt to free unreferenced scalar: SV 0x40601238 at /usr/lib/perl5/site_perl/5.8.2/i686-linux-thread-multi/DBI.pm line 633. [Wed Feb 18 10:12:34 2004] [notice] caught SIGTERM, shutting down Stas asked me if I could make a 'test' case to display this behaviour; I have not been able to reproduce this problem outside if my apache2/mod_perl 2/mason/etc. server setup yet. OK, I thought DBI has resolved this issue, but apparently it's still on the TODO list: /home/stas/.cpan/build/DBI-1.40 grep -Ir PERL_NO_GET_CONTEXT . ./ToDo:Add PERL_NO_GET_CONTEXT for multiplicity/threads? But it's not longer an apreq problem (either 1 or 2). Anyway, I now have a test bed that I can fire up on my test server whenever more patches are forthcoming (If you folks need it). Now someone needs to patch DBI and send it to Tim. It's a good exercise to learn about the contexts if anybody is willing to learn. Once this is added, DBI won't have this problem under 5.8.2 any longer. If you decide to do it and need help, let me know. BTW, the latest DBI dev is available via svn: http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI-dev/1987815 __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [apreq2] proper support for ithreads
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 on the TODO list: /home/stas/.cpan/build/DBI-1.40 grep -Ir PERL_NO_GET_CONTEXT . ./ToDo:Add PERL_NO_GET_CONTEXT for multiplicity/threads? But it's not longer an apreq problem (either 1 or 2). [...] Now someone needs to patch DBI and send it to Tim. It's a good exercise to learn about the contexts if anybody is willing to learn. Once this is added, DBI won't have this problem under 5.8.2 any longer. If you decide to do it and need help, let me know. BTW, the latest DBI dev is available via svn: http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI-dev/1987815 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. Anyway, sure, I should have time this week for DBI (and then maybe I can attack Mason), but I'll need some coaching to fix DBI. So as a plan, I'll get DBI and try to make some headway; when I have a better feeling for how to fix the problem, I'll post questions here, OK? Aloha = Beau; -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [apreq2] proper support for ithreads
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 warnings go away with 5.8.3? Do you get them only when using DBI or with out as well? If Mason doesn't use XS, which modules that use XS does it load? Anyway, sure, I should have time this week for DBI (and then maybe I can attack Mason), but I'll need some coaching to fix DBI. So as a plan, I'll get DBI and try to make some headway; when I have a better feeling for how to fix the problem, I'll post questions here, OK? Sure. This is relevant to any XS module. You start by including: #define PERL_NO_GET_CONTEXT before these loads: #include EXTERN.h #include perl.h #include XSUB.h So in case of DBI, that would be: --- DBIXS.h.orig2004-02-18 13:46:24.0 -0800 +++ DBIXS.h 2004-02-18 13:46:53.0 -0800 @@ -14,6 +14,7 @@ #endif /* first pull in the standard Perl header files for extensions */ +#define PERL_NO_GET_CONTEXT /* we want efficiency */ #define PERL_POLLUTE #include EXTERN.h #include perl.h then, when you build things. You will start getting errors like these: In file included from Perl.c:40: Driver_xst.h: In function `dbixst_bounce_method': Driver_xst.h:14: error: `my_perl' undeclared (first use in this function) Driver_xst.h:14: error: (Each undeclared identifier is reported only once Driver_xst.h:14: error: for each function it appears in.) Driver_xst.h: In function `dbdxst_bind_params': Driver_xst.h:54: error: `my_perl' undeclared (first use in this function) Driver_xst.h: In function `dbdxst_fetchall_arrayref': Driver_xst.h:75: error: `my_perl' undeclared (first use in this function) So you need to add pTHX/pTHX_ as the first argument in function declarations and aTHX/aTHX_ in the function calls. And eventually these errors will go away. Do not use dTHX, since it reverts things to the way they were before. And as you go eliminate any dTHX calls that you use. For more information please refer to the perlguts manpage, when it talks about: The third, even more efficient way is to ape how it is done within the Perl guts: ... now any follow ups to this specific issue of DBI should probably go to the dbi-dev mailing list, since it's off topic to this list. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: License 2.0
--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
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 modules, we can relicense them at that time. -- justin I'd like to see those modules pulled into one big-ass SVN repository with all the rest of the HTTPD PMC's code. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [apreq2] proper support for ithreads
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 /usr/lib/perl5/site_perl/5.8.2/HTML/Mason/Request.pm line 161. And these warnings go away with 5.8.3? Do you get them only when using DBI or with out as well? If Mason doesn't use XS, which modules that use XS does it load? Yes, the warnings go away with 5.8.3. I have not tried w/o DBI. No, Mason does not use XS directly. I don't know what 'XS' modules Mason loads, but will investigate. Thanks for the tutorial. I'm busy getting subversion installed; Will get back to you soon. Aloha = Beau; -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Time for 1.3.30??
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 mod_whatkilledus in experimental? I saw statements from 2 or 3 folks that seemed interested and I'd be happy to address the outstanding comments and suggestions (fix the directive names, escape the request info written by whatkilledus, allow mod_backtrace to be built on FreeBSD since there is a libexecinfo available there with the required function). No integration with the build planned unless somebody else wants to deal with the AP_ENABLE_EXCEPTION_HOOK flag ;) +1. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: Time for 1.3.30??
* 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 replacing the BSD-style old license that entirely works off the grounds of copyright law by this new beast that requires a bazillion of lawyers to parse and almost certainly goes into contract law? i will not import any code under the new apache license into openbsd. if that means we have to fork 1.3.29, then so it be, even though that is not the option i prefer. very sad. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Time for 1.3.30??
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 the point of replacing the BSD-style old license that entirely works off the grounds of copyright law by this new beast that requires a bazillion of lawyers to parse and almost certainly goes into contract law? You will find the venue where that work was done here: http://nagoya.apache.org/eyebrowse/SummarizeList?listId=178 That mailing list is the right place to raise your concerns and, I hope, get them resolved. Since this is a decision that we have labored on across the entire foundation it's just not effective to try and discuss it in this mailing list. - ben
Changing rec status field in output filter chain
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 it possible, and if yes, then how could I replace the 304 Not Modified with a200 OK before sending the response to the client? Thanks, Jean-Jacques
Re: Add Exception Hooks to 2.0
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 ;) Tested on linux with prefork and worker - seems to work well. All that seems to be missing are the config directives. Also, I've tested the patch today on Solaris 9 with prefork and worker and threadpool. Yes, the difference between 1.3 and 2.1-dev w.r.t. the config directive is glaring :( I'll try to commit a remedy to 2.1-dev soonish, and add that to the patch for hopeful backport to APACHE_2_0_BRANCH. Thanks for your testing and feedback, Jeff
[STATUS] (apache-1.3) Wed Feb 18 23:45:11 EST 2004
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. 1.3.28: Tagged July 16, 2003. Announced ?? 1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002. 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, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the first minutes due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at last minute due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9, 1999. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7, 1998. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19, 1998. Announced and released. 1.3.0: Tagged and rolled on June 1, 1998. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * Bugz: 24483 RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * isn't ap_die() broken with recognizing recursive errors Message-Id: [EMAIL PROTECTED] +1: jeff, jim * Current vote on 3 PRs for inclusion: Bugz #17877 (passing chunked encoding thru proxy) (still checking if RFC compliant... vote is on the correctness of the patch code only). +1: jim, chuck, minfrin Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message [EMAIL PROTECTED]) * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: [EMAIL PROTECTED] Status: * Dean's unescaping hell (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: [EMAIL PROTECTED] Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-server pointer when being dereferenced by invoking httpd -S. Message-ID: [EMAIL PROTECTED] Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define Directory / with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: [EMAIL PROTECTED] Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker [EMAIL PROTECTED] to more fully close some segfault potential. Message-ID: [EMAIL PROTECTED] Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: [EMAIL PROTECTED] Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: [EMAIL PROTECTED] Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to
[STATUS] (httpd-2.1) Wed Feb 18 23:45:19 EST 2004
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 projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the PatchAvailable bugs in the bug database. Append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 CURRENT VOTES: * Promote mod_cache from experimental to non-experimental status (keep issues noted below in EXPERIMENTAL MODULES as items to be addressed as a supported module). +1: jim, bnicholes -0: jerenkrantz -1: stoddard There are a couple of problems that need to be resolved before this module is moved out of experimental. 1) We need to at least review and comment on the RFC violations 2) Resolve issue of how to cache page fragements (or perhaps -if- we want to cache page fragements). Today, mod_cache/mod_mem_cache will cache #include 'virtual' requests (but not #include 'file' requests). This was accomplished by making CACHE_IN a CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE filter. But now responses cannot be cached that include the effects of having been run through CONTENT_SET filters (mod_deflate, mod_expires, etc). We could rerun all the CONTENT_SET filters on the cached response, but this will not work in all cases. For example, mod_expires relies on installing the EXPIRATION filter during fixups. Contents served out of mod_cache (out of the quick_handler) bypass -all- the request line server hooks (Ryan really hated this. It is great for performance, but bad because of the complications listed above). jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla for mod_cache (see 'RFC 2616 violations' below). I think fixing them is a pre-requisite before it isn't experimental. * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database:
