[PATCH] module2path/module2url pod
Here's my first crack at pod for module2path and module2url.
I decided to put it at the end of the FUNCTONS head1. It didn't seem to
make much sense at the beginning and it felt like I should keep focus on
the exported functions.
Let me know if you had something else in mind and I'll rework it.
-=Chris
Index: lib/Apache/TestRequest.pm
===
--- lib/Apache/TestRequest.pm (revision 94)
+++ lib/Apache/TestRequest.pm (working copy)
@@ -1088,6 +1088,50 @@
specification, section 9.2, at
Ihttp://www.faqs.org/rfcs/rfc2616.html for more information.
+=head2 Helper Functions
+
+CApache::TestRequest also includes a few helper functions to aid in
+the creation of urls used in the functions above.
+
+=over 4
+
+=item module2path
+
+ my $module = 'MyTestModule::TestHandler';
+ my $path = Apache::TestRequest::module2path($module);
+# returns 'MyTestModule__TestHandler'
+
+ my $res = GET /$path;
+
+Converts a module name to a path safe for use in the various request
+methods above.
+
+=item module2url
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri= Apache::TestRequest::module2url($module);
+# returns 'http://host:port/MyTestModule__TestHandler'
+
+ my $res = GET $uri;
+
+Converts a module name to a full uri including the current
+configurations host:port and sets Cmodule accordingly.
+
+The default scheme used is Chttp. You can override this by passing
+your preferred scheme into an optional second param:
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri = Apache::TestRequest::module2uri($module, {scheme = 'https'});
+# returns 'https://host:port/MyTestModule__TestHandler'
+
+You may also override the default path with a path of your own:
+
+ my $module = 'MyTestModule::TestHandler';
+ my $uri = Apache::TestRequest::module2uri($module, {path = '/foo'});
+# returns 'http://host:port/foo'
+
+=back
+
=head1 ENVIRONMENT VARIABLES
The following environment variables can affect the behavior of
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
As soon as you see dup like this, think refactoring :) e.g. add
untaint_path(), that does the work and call it:
local $ENV{PATH}) = untaint_path($ENV{PATH});
Otherwise +1.
And of course this wrapper should probably used in open_cmd too!
Here's a patch that does that:
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 56)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1045,12 +1045,8 @@
my($self, $cmd) = @_;
# untaint some %ENV fields
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
-# Temporarily untaint PATH
-(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
-# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
-
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1663,7 +1659,8 @@
return unless $self-{APXS};
my $val;
unless (exists $self-{_apxs}{$q}) {
-local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
+local @ENV{ qw(IFS CDPATH ENV BASH_ENV) };
+local $ENV{PATH} = untaint_path($ENV{PATH});
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
@@ -1684,6 +1681,17 @@
$self-{_apxs}{$q};
}
+# Temporarily untaint PATH
+sub untaint_path {
+my $path = shift;
+($path) = ( $path =~ /(.*)/ );
+# win32 uses ';' for a path separator, assume others use ':'
+my $sep = WIN32 ? ';' : ':';
+# -T disallows relative directories in the PATH
+$path = join $sep, grep !/^\./, split /$sep/, $path;
+return $path;
+}
+
sub pop_dir {
my $dir = shift;
==
I tried committing it, but was denied access (I ensured I
did a co with https); perhaps some permissions need
adjusting (I did have commit access under cvs).
--
best regards,
randy
Re: [PATCH] module2path/module2url pod
Christopher H. Laco wrote: Here's my first crack at pod for module2path and module2url. I decided to put it at the end of the FUNCTONS head1. It didn't seem to make much sense at the beginning and it felt like I should keep focus on the exported functions. There is already one head1 FUNCTIONS there. I've called your header: =head2 URL Manipulation Functions since all function in this module are 'helper functions' :) Let me know if you had something else in mind and I'll rework it. Looks good. I've massaged it a bit and commited. Thanks Chris. -- __ 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
Re: apxs calls on Win32
Randy Kobes wrote: On Wed, 8 Dec 2004, Stas Bekman wrote: I've requested to restore it (you indeed don't have it). Let me know if you want me to commit this or wait for when you get the access again (should hopefully be restored tomorrow). Thanks, Stas. If you have a minute, feel free to commit it; otherwise, I'll do it when it's restored. Thanks. It's in. -- __ 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
Re: [OT] CVS - SVN Thoughts
Christopher H. Laco wrote: This is mostly off topic, but I wanted to get thoughts from the committers on how they're liking the conversion from CVS to SVN so far. What do you really like/hate about it vs. CVS? I've been toying around with the idea of moving that way at home. I'm not to sure I'm keen having to use copy for tagging and such, but maybe that's just the CVS brainwashing in me. I do dig the http/WebDAV background. It seems a lot easier to give the world read access. I guess this is a wrong forum. May be you will have a better luck with svn users list, whatever it is? Personally I haven't done any moves myself yet, so I can't tell. -- __ 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
Re: Building flood on AMD64
On Sat, Dec 04, 2004 at 09:25:59PM -0600, Robert Lowe wrote: Hi! I tried building flood-0.4 on an AMD64 box running FC3 but stalled immediately: checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized configure: error: /bin/sh ./config.sub x86_64-unknown-linux-gnu failed Any way around this?? Try flood from cvs because 0.4 is prehistoric and update config.sub and config.guess. Never tried it myself but that seems the logical next step. Philippe
Re: apxs calls on Win32
Stas Bekman [EMAIL PROTECTED] writes: I've requested to restore it (you indeed don't have it). Sorry about that Randy. I've been trying for weeks to get our httpd-test commit access restored. -- Joe Schaefer
Re: [PATCH] module2path/module2url pod
Stas Bekman wrote:
Christopher H. Laco wrote:
Here's my first crack at pod for module2path and module2url.
I decided to put it at the end of the FUNCTONS head1. It didn't seem
to make much sense at the beginning and it felt like I should keep
focus on the exported functions.
There is already one head1 FUNCTIONS there.
I've called your header:
=head2 URL Manipulation Functions
since all function in this module are 'helper functions' :)
Let me know if you had something else in mind and I'll rework it.
Looks good. I've massaged it a bit and commited.
Thanks Chris.
Shouldn't that be:
Index: TestRequest.pm
===
--- TestRequest.pm (revision 111269)
+++ TestRequest.pm (working copy)
@@ -1121,7 +1121,7 @@
=head3 Cmodule2url
$url = Apache::TestRequest::module2url($module);
- $url = Apache::TestRequest::module2url($module, %options);
+ $url = Apache::TestRequest::module2url($module, \%options);
Convert a module name to a full URL including the current
configurations Chostname:port and sets Cmodule accordingly.
Maybe it's just me. The former leads me to believe that I might be able
to do:
module2url('MyMod::Test',
scheme = 'https', path = '/merge3/');
instead of
module2url('MyMod::Test',
{scheme = 'https', path = '/merge3/'});
while the later make that more clear.
Any other grunt work can work on?
-=Chris
Re: [PATCH] module2path/module2url pod
Christopher H. Laco wrote: Shouldn't that be: Index: TestRequest.pm - $url = Apache::TestRequest::module2url($module, %options); + $url = Apache::TestRequest::module2url($module, \%options); Thanks Chris, fixed. Any other grunt work can work on? if you didn't get tired from module2url manipulations, there are a few tests in the httpd-test repository that could use the same refactoring. This is the repository used by the httpd project. To exract it do: svn checkout http://svn.apache.org/repos/asf/httpd/test/trunk/ httpd-test it lives in httpd-test/perl-framework/t/ Other than that, I'm going to commit soon a new test framework that tests Apache-Test config itself, so you may want to help out with that, once it's in. You are on the [EMAIL PROTECTED] list, right? That list shows all the commits to the httpd-test project (which includes Apache-Test). -- __ 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
Re: [PATCH] fixing broken gnu ld (mis)detection problem
On Tue, 7 Dec 2004 21:53:07 +0100, Enrico Weigelt [EMAIL PROTECTED] wrote: here's a patch against httpd-2.0.49 which fixes the broken configure script. we don't maintain configure; it is autogenerated; any fixes need to be in the input files; it looks like the portion you had to modify comes from libtool sources, not from Apache httpd sources; have you tried installing a later libtool and running buildconf to regenerate configure?
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
It may be a bit of a hack, but it seems reasonable to me. The best
part is that it works.
+1
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 2:33:48 AM
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this
is
because there is more than one filter stack that needs to be
modified?
Yes. I think this fixes it, it's a bit of a hack though:
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 59)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1184,22 +1184,26 @@
apr_bucket *b;
SSL *ssl;
-/* Just remove the filter, if it doesn't work the first time, it
won't
- * work at all for this request.
- */
-ap_remove_output_filter(f);
+/* f-ctx is non-NULL after the first call to this filter: it's
+ * necessary to pass through directly to the connection
output_filters
+ * for the remainder of this request, since the SSL output filter
has
+ * not been added to r-output_filters for this request. */
+if (f-ctx) {
+return ap_pass_brigade(f-c-output_filters, bb);
+}
-/* No need to ensure that this is a server with optional SSL, the
filter
- * is only inserted if that is true.
- */
-
+/* No need to ensure that this is a server with optional SSL, the
+ * filter is only inserted if that is true. */
upgrade = apr_table_get(r-headers_in, Upgrade);
if (upgrade == NULL
|| strcmp(ap_getword(r-pool, upgrade, ','), TLS/1.0)) {
/* Upgrade: TLS/1.0, ... header not found, don't do Upgrade
*/
+ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
+f-ctx = f; /* flag as non-NULL for subsequent passes */
+
apr_table_unset(r-headers_out, Upgrade);
/* Send the interim 101 response. */
@@ -1245,7 +1249,6 @@
pass the brigade off to the connection based output filters so
that the
request can complete encrypted */
return ap_pass_brigade(f-c-output_filters, bb);
-
}
static apr_status_t ssl_io_filter_input(ap_filter_t *f,
Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)
FYI, if anybody else is interesting is testing the TLS upgrade
functionality, there is a small test utility
(http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send
an upgradeable GET or POST request.
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 9:01:22 AM
It may be a bit of a hack, but it seems reasonable to me. The best
part is that it works.
+1
Brad
[EMAIL PROTECTED] Wednesday, December 08, 2004 2:33:48 AM
On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote:
OK, now that you have enabled upgrades for anything other than
OPTIONS, I see the problem. Even though there is a content-length
included in the header, you are saying that the header is being sent
encrypted but the content is not, correct? And the reason for this
is
because there is more than one filter stack that needs to be
modified?
Yes. I think this fixes it, it's a bit of a hack though:
Index: modules/ssl/ssl_engine_io.c
===
--- modules/ssl/ssl_engine_io.c (revision 59)
+++ modules/ssl/ssl_engine_io.c (working copy)
@@ -1184,22 +1184,26 @@
apr_bucket *b;
SSL *ssl;
-/* Just remove the filter, if it doesn't work the first time, it
won't
- * work at all for this request.
- */
-ap_remove_output_filter(f);
+/* f-ctx is non-NULL after the first call to this filter: it's
+ * necessary to pass through directly to the connection
output_filters
+ * for the remainder of this request, since the SSL output filter
has
+ * not been added to r-output_filters for this request. */
+if (f-ctx) {
+return ap_pass_brigade(f-c-output_filters, bb);
+}
-/* No need to ensure that this is a server with optional SSL, the
filter
- * is only inserted if that is true.
- */
-
+/* No need to ensure that this is a server with optional SSL, the
+ * filter is only inserted if that is true. */
upgrade = apr_table_get(r-headers_in, Upgrade);
if (upgrade == NULL
|| strcmp(ap_getword(r-pool, upgrade, ','), TLS/1.0)) {
/* Upgrade: TLS/1.0, ... header not found, don't do Upgrade
*/
+ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
+f-ctx = f; /* flag as non-NULL for subsequent passes */
+
apr_table_unset(r-headers_out, Upgrade);
/* Send the interim 101 response. */
@@ -1245,7 +1249,6 @@
pass the brigade off to the connection based output filters so
that the
request can complete encrypted */
return ap_pass_brigade(f-c-output_filters, bb);
-
}
static apr_status_t ssl_io_filter_input(ap_filter_t *f,
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
--On Wednesday, December 8, 2004 9:33 AM + Joe Orton [EMAIL PROTECTED] wrote: On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote: OK, now that you have enabled upgrades for anything other than OPTIONS, I see the problem. Even though there is a content-length included in the header, you are saying that the header is being sent encrypted but the content is not, correct? And the reason for this is because there is more than one filter stack that needs to be modified? Yes. I think this fixes it, it's a bit of a hack though: Isn't this the issue Stas keeps bringing up about the filters? See STATUS - in particular the edge connection filter cannot be removed - I believe it's listed as a showstopper currently. Should we invest time to just fix this the 'right' way? IIRC, the only real way to fix it is to go back to a doubly-linked list of some sort. But, there might be some other clever ways of dealing with this. *shrug* -- justin
Re: Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)
At 10:10 AM 12/8/2004, Brad Nicholes wrote: FYI, if anybody else is interesting is testing the TLS upgrade functionality, there is a small test utility (http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send an upgradeable GET or POST request. It seems to me we can make ab.c TLS upgrade-aware by; 1. recognizing the -s flag in conjunction with http: - that would set the ssl preference client-side. (This would not alter the behavior of https:, or of -s without a scheme.) 2. recognize upgrade-required and promote an http: connection to SSL when the server-side demands it. Sane? Bill
Re: 2.1 CVS: ftp proxy probably broken
On Thu, 14 Oct 2004 15:52:05 +0200, Andreas Steinmetz [EMAIL PROTECTED] wrote: Did anybody notice that the ftp proxy seems to be broken? Any request returns 503 and the reason seems to be that ap_proxy_connect_backend is called with conn-addr=NULL from ap_proxy_ftp_handler. I can't get it to work either. There also seems to be a slight regression in ProxyPass support for ftp. The following directive is accepted by 2.0 but not by 2.1: proxypass /ftp1 ftp://dummy:[EMAIL PROTECTED]/ 2.1 says invalid port at config parsing time. Unfortunately, 2.0 doesn't process it correctly at the time of the request, because it tries to grab user and password from the wrong parsed URI, but that seems easy enough to fix. Somebody please call me a liar (proxy ftp really does work in 2.1 or ProxyPass ftp really does work with password in 2.0).
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
On Wed, Dec 08, 2004 at 08:22:49AM -0800, Justin Erenkrantz wrote: --On Wednesday, December 8, 2004 9:33 AM + Joe Orton [EMAIL PROTECTED] wrote: On Tue, Dec 07, 2004 at 05:14:40PM -0700, Brad Nicholes wrote: OK, now that you have enabled upgrades for anything other than OPTIONS, I see the problem. Even though there is a content-length included in the header, you are saying that the header is being sent encrypted but the content is not, correct? And the reason for this is because there is more than one filter stack that needs to be modified? Yes. I think this fixes it, it's a bit of a hack though: Isn't this the issue Stas keeps bringing up about the filters? See STATUS - in particular the edge connection filter cannot be removed - I believe it's listed as a showstopper currently. Should we invest time to just fix this the 'right' way? IIRC, the only real way to fix it is to go back to a doubly-linked list of some sort. But, there might be some other clever ways of dealing with this. Ah very interesting, yes, it's essentially the same issue. It looks like using a doubly-linked list would solve this case as well. I can't convince myself it would solve the general case, though: if both r- and c-output_filters to happen point to the *same* filter, modifying the filter chain without knowledge of r- (which is the problem) will still break if the filter must be inserted in the -prev position? joe
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
--On Wednesday, December 8, 2004 8:53 PM + Joe Orton [EMAIL PROTECTED] wrote: I can't convince myself it would solve the general case, though: if both r- and c-output_filters to happen point to the *same* filter, modifying the filter chain without knowledge of r- (which is the problem) will still break if the filter must be inserted in the -prev position? We'd likely have to switch r-output_filters (and perhaps c-output_filters) to use double-indirection (**) - so that we can change the underlying pointer and update all 'pointers' at the same time. -- justin
Re: Testing TLS Upgrade (was: Re: Patch for bug 18757 breaks TLS upgrade)
Seems reasonable. I would have to take a closer look at it though. Brad [EMAIL PROTECTED] Wednesday, December 08, 2004 10:56:10 AM At 10:10 AM 12/8/2004, Brad Nicholes wrote: FYI, if anybody else is interesting is testing the TLS upgrade functionality, there is a small test utility (http://www.apache.org/~bnicholes/tlsupgrade.c) that can be used to send an upgradeable GET or POST request. It seems to me we can make ab.c TLS upgrade-aware by; 1. recognizing the -s flag in conjunction with http: - that would set the ssl preference client-side. (This would not alter the behavior of https:, or of -s without a scheme.) 2. recognize upgrade-required and promote an http: connection to SSL when the server-side demands it. Sane? Bill
[STATUS] (apache-1.3) Wed Dec 8 23:45:05 EST 2004
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2004/10/30 13:20:38 $] Release: 1.3.34-dev: In development. 1.3.33: Tagged October 27, 2004 1.3.32: Tagged October 18, 2004. Not formally released. 1.3.31: Tagged May 7, 2004. Announced May 11, 2004. 1.3.30: Tagged April 9, 2004. Not released. 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: PROPOSED PATCHES FOR THIS RELEASE: *) mod_log_config: Cleanup log_header_out function to allow multiple headers like Set-Cookie to be logged properly. PR 27787 modules/loggers/mod_log_config.c: r1.116 (2.x patch - need 1.3 version) jerenkrantz asks: Isn't this what apr_table_merge is for? nd replies: yep. But cookies won't be merged, because browsers don't support it. jerenkrantz: Couldn't we copy the table and merge the values somehow? This just seems like a lot of code to duplicate what we have already. *shrug* +1: nd, jerenkrantz -1: jim (until we see the 1.3 version) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * PR: 27023 Cookie could not delivered if the cookie made before proxy module. * 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:
[STATUS] (httpd-2.0) Wed Dec 8 23:45:10 EST 2004
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/11/10 18:05:46 $]
Release:
2.0.53 : in development
2.0.52 : released September 28, 2005 as GA.
2.0.51 : released September 15, 2004 as GA.
2.0.50 : released June 30, 2004 as GA.
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
2.0.46 : released May 28, 2003 as GA.
2.0.45 : released April 1, 2003 as GA.
2.0.44 : released January 20, 2003 as GA.
2.0.43 : released October 3, 2002 as GA.
2.0.42 : released September 24, 2002 as GA.
2.0.41 : rolled September 16, 2002. not released.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
2.0.38 : rolled June 16, 2002. not released.
2.0.37 : rolled June 11, 2002. not released.
2.0.36 : released May 6, 2002 as GA.
2.0.35 : released April 5, 2002 as GA.
2.0.34 : tagged March 26, 2002.
2.0.33 : tagged March 6, 2002. not released.
2.0.32 : released Feburary 16, 2002 as beta.
2.0.31 : rolled Feburary 1, 2002. not released.
2.0.30 : tagged January 8, 2002. not rolled.
2.0.29 : tagged November 27, 2001. not rolled.
2.0.28 : released November 13, 2001 as beta.
2.0.27 : rolled November 6, 2001
2.0.26 : tagged October 16, 2001. not rolled.
2.0.25 : rolled August 29, 2001
2.0.24 : rolled August 18, 2001
2.0.23 : rolled August 9, 2001
2.0.22 : rolled July 29, 2001
2.0.21 : rolled July 20, 2001
2.0.20 : rolled July 8, 2001
2.0.19 : rolled June 27, 2001
2.0.18 : rolled May 18, 2001
2.0.17 : rolled April 17, 2001
2.0.16 : rolled April 4, 2001
2.0.15 : rolled March 21, 2001
2.0.14 : rolled March 7, 2001
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2.0a5 : released August 4, 2000
2.0a4 : released June 7, 2000
2.0a3 : released April 28, 2000
2.0a2 : released March 31, 2000
2.0a1 : released March 10, 2000
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.
RELEASE SHOWSTOPPERS:
PATCHES TO BACKPORT FROM 2.1
[ please place file names and revisions from HEAD here, so it is easy to
identify exactly what the proposed changes are! ]
*) mod_ssl: Fix an possible NULL pointer dereference in some configs.
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=13182
PR: 31848
+1: jorton, wrowe, jim
*) Allow for the use of --with-module=foo:bar where the ./modules/foo
directory is a local addition to the ./modules directory.
Assumes, of course, that the required files are in ./modules/foo,
but makes it easier to statically build external modules by
simply adding them to ./modules.
modules/config5.m4: 1.4
+1: jim, jerenkrantz
+0: wrowe
(would rather see --with-module-lib=foo --enable-bar=shared syntax to
support multiple libs, module modules. Might need to pass the
--with-module-lib=foo to ./buildconf instead.)
*) several changes to improve logging of connection-oriented errors,
including
ap_log_cerror() API (needs minor bump in addition to changes below)
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289r2=1.291
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150r2=1.151
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46r2=1.48
+1: trawick
*) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP
library handles special characters.
http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12919
PR 24437
+1: minfrin, wrowe, jim
*) Fix ap_save_brigade's handling of ENOTIMPL setaside functions.
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/util_filter.c?r1=1.100r2=1.102
PR: 31247
+1: jorton
*) mod_headers: Support {...}s tag for SSL variable lookup.
http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff
+1: jorton, trawick
nd: two comments:
(1) is the use of APR_ASCII_* ebcdic-safe? I.e. shouldn't we use the
native chars here and it will be converted later? (I'm not sure)
jorton: I have no idea, let an EBCDIC-er complain if it breaks?
trawick: seems that '\r' and '\n' are the better chars to check
for; this is not raw data read from
[STATUS] (httpd-2.1) Wed Dec 8 23:45:16 EST 2004
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/11/06 08:28:24 $] Release [NOTE that only Alpha/Beta releases occur in 2.1 development]: 2.1.1 : Proposed roll on 11/14/2004 (around/after Hackathon). Justin volunteers as RM. 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: * When the CVS-SVN is done, there's a bogus avendor branch that should be removed from most files. The branch was created 4/27/2004. It's safest (and easiest) for now just to leave it in there; the MAIN branch and the APACHE_2_0_BRANCH are untouched and unharmed. --jwoolley RELEASE SHOWSTOPPERS: * Convert httpd-2.x to Subversion. Yes, we've voted on this a billion times on [EMAIL PROTECTED], but let's make this one official. Majority rules. +1: jerenkrantz, pquerna * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 jerenkrantz asks: Why should this block a release? * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? 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: jerenkrantz, pquerna +0: jim, bnicholes -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: I think it's time. We've done a *lot* of work to it, and we think most of the blatant RFC violations are now gone. mod_cache just belongs in cache/. There may still be bugs, but not likely to be major ones. Note that I'm not moving *anything* until we switch to SVN. * 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
Re: [STATUS] (httpd-2.0) Wed Dec 8 23:45:10 EST 2004
2.0.52 : released September 28, 2005 as GA.
should be
2.0.52 : released September 28, 2004 as GA.
On Wed, 8 Dec 2004 23:45:11 -0500, Rodent of Unusual Size
[EMAIL PROTECTED] wrote:
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2004/11/10 18:05:46 $]
Release:
2.0.53 : in development
2.0.52 : released September 28, 2005 as GA.
2.0.51 : released September 15, 2004 as GA.
2.0.50 : released June 30, 2004 as GA.
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
2.0.46 : released May 28, 2003 as GA.
2.0.45 : released April 1, 2003 as GA.
2.0.44 : released January 20, 2003 as GA.
2.0.43 : released October 3, 2002 as GA.
2.0.42 : released September 24, 2002 as GA.
2.0.41 : rolled September 16, 2002. not released.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
2.0.38 : rolled June 16, 2002. not released.
2.0.37 : rolled June 11, 2002. not released.
2.0.36 : released May 6, 2002 as GA.
2.0.35 : released April 5, 2002 as GA.
2.0.34 : tagged March 26, 2002.
2.0.33 : tagged March 6, 2002. not released.
2.0.32 : released Feburary 16, 2002 as beta.
2.0.31 : rolled Feburary 1, 2002. not released.
2.0.30 : tagged January 8, 2002. not rolled.
2.0.29 : tagged November 27, 2001. not rolled.
2.0.28 : released November 13, 2001 as beta.
2.0.27 : rolled November 6, 2001
2.0.26 : tagged October 16, 2001. not rolled.
2.0.25 : rolled August 29, 2001
2.0.24 : rolled August 18, 2001
2.0.23 : rolled August 9, 2001
2.0.22 : rolled July 29, 2001
2.0.21 : rolled July 20, 2001
2.0.20 : rolled July 8, 2001
2.0.19 : rolled June 27, 2001
2.0.18 : rolled May 18, 2001
2.0.17 : rolled April 17, 2001
2.0.16 : rolled April 4, 2001
2.0.15 : rolled March 21, 2001
2.0.14 : rolled March 7, 2001
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2.0a5 : released August 4, 2000
2.0a4 : released June 7, 2000
2.0a3 : released April 28, 2000
2.0a2 : released March 31, 2000
2.0a1 : released March 10, 2000
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.
RELEASE SHOWSTOPPERS:
PATCHES TO BACKPORT FROM 2.1
[ please place file names and revisions from HEAD here, so it is easy to
identify exactly what the proposed changes are! ]
*) mod_ssl: Fix an possible NULL pointer dereference in some configs.
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=13182
PR: 31848
+1: jorton, wrowe, jim
*) Allow for the use of --with-module=foo:bar where the ./modules/foo
directory is a local addition to the ./modules directory.
Assumes, of course, that the required files are in ./modules/foo,
but makes it easier to statically build external modules by
simply adding them to ./modules.
modules/config5.m4: 1.4
+1: jim, jerenkrantz
+0: wrowe
(would rather see --with-module-lib=foo --enable-bar=shared syntax
to
support multiple libs, module modules. Might need to pass the
--with-module-lib=foo to ./buildconf instead.)
*) several changes to improve logging of connection-oriented errors,
including
ap_log_cerror() API (needs minor bump in addition to changes below)
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289r2=1.291
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150r2=1.151
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46r2=1.48
+1: trawick
*) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP
library handles special characters.
http://issues.apache.org/bugzilla/showattachment.cgi?attach_id=12919
PR 24437
+1: minfrin, wrowe, jim
*) Fix ap_save_brigade's handling of ENOTIMPL setaside functions.
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/util_filter.c?r1=1.100r2=1.102
PR: 31247
+1: jorton
*) mod_headers: Support {...}s tag for SSL variable lookup.
http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff
+1: jorton, trawick
nd: two comments:
(1) is the use of
Re: [STATUS] (httpd-2.0) Wed Dec 8 23:45:10 EST 2004
On Thu, 9 Dec 2004, hutuworm wrote: 2.0.52 : released September 28, 2005 as GA. should be 2.0.52 : released September 28, 2004 as GA. LOL. :) There's been a new breakthrough in home video marketing. Instant cassettes. They're out in stores before the movie is finished. I'll go fix that.
Re: [STATUS] (httpd-2.1) Wed Dec 8 23:45:16 EST 2004
--On Wednesday, December 8, 2004 11:45 PM -0500 Rodent of Unusual Size [EMAIL PROTECTED] wrote: APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2004/11/06 08:28:24 $] Ken: FWIW, httpd has switched to Subversion (and APR has too). Is it possible to get your scripts updated? Thanks! -- justin
Re: 2.1 CVS: ftp proxy probably broken
Jeff Trawick wrote: On Thu, 14 Oct 2004 15:52:05 +0200, Andreas Steinmetz [EMAIL PROTECTED] wrote: Did anybody notice that the ftp proxy seems to be broken? I can't get it to work either. There also seems to be a slight regression in ProxyPass support for ftp. The following directive is accepted by 2.0 but not by 2.1: proxypass /ftp1 ftp://dummy:[EMAIL PROTECTED]/ 2.1 says invalid port at config parsing time. Hm, the current algo presumes scheme://host[:port]. I'll see if apr_uri_parse will allow parsing ajp and balancer schemes. Regards, Mladen.
Re: 2.1 CVS: ftp proxy probably broken
Andreas Steinmetz wrote: Did anybody notice that the ftp proxy seems to be broken? Any request returns 503 and the reason seems to be that ap_proxy_connect_backend is called with conn-addr=NULL from ap_proxy_ftp_handler. Fix is trivial. I'll commit the patch as soon as SVN gets up :). Mladen.
