Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote:
Christopher H. Laco wrote:
On that note, what else can I work on?
Apparently I'm a glutton for punishment.
Not sure, there are all kind of things in the ToDo file, but they all
mostly obscure.
I think all kind of refactoring would be great. One thing I wanted to do
for tests again vhosts, is to add this function next to module2path():
sub module2url {
my $module = shift;
my $scheme = shift || http;
Apache::TestRequest::module($module);
my $config = Apache::Test::config();
my $hostport = Apache::TestRequest::hostport($config);
my $path = Apache::TestRequest::module2path($module);
return $scheme://$hostport$path;
}
and then replace the long craft used a lot in the modperl tests, so now
one can write a simple:
my $module = Foo::bar;
{
my $path = Apache::TestRequest::module2path($module);
GET $path; # GET /Foo__bar
}
{
my $url = Apache::TestRequest::module2url($module);
GET $url; # GET http://localhost:8545/Foo__bar;
}
grep modperl-2.0/t for Apache::TestRequest::hostport to see what I'm
talking about.
OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm
going to just start with t/modperl and go from there.
Since these patches will span A-T and modperl, should I send them
seperately to both lists, of send both sets to one list of the other?
-=Chris
Re: [PATCH] Test TestRequest pod
Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) -- __ 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] Test TestRequest pod
Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? if they include modperl and a-t send them to the modperl dev list. if only a-t post them here. thanks :) Another opinion question amungst the A-TR and t/modperl changes: module2url vs. module2uri and my $url =vs. my $uri = Frankly I can never tell the difference (I know there is one). I normally use url... but whatever you like -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? If you use a relative path, it just goes to the default http://localhost:8529/. Not madness but for the sake of simplicity. Use relative path, unless you want to talk to a different port. -- __ 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] Test TestRequest pod
Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. -- __ 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] Test TestRequest pod
Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. Baby steps, Chris. Baby steps. I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Stas Bekman wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: Christopher H. Laco wrote: OK, not that I've got a clean nmake/nmake test, I'm back on this. I'm going to just start with t/modperl and go from there. Since these patches will span A-T and modperl, should I send them seperately to both lists, of send both sets to one list of the other? -=Chris I've also noticed that some tests in t/modperl simply set their location my $location = /TestModperl__readline; while other tests use a full uri including the server/port (hostport, now module2url). Should all of them use the latter method for consistancy sake, or is there a reason for the madness? Thanks. -=Chris Assuming we should always GET/POST/HEAD/UPLOAD to the full host:port/path and not just /path, what about making a more generic path2url($path) that uses config/hostport to create the full url. Then we can run module2url's path through that and use path2url for the test cases like t/modperl/readline.t that don't set A::TR::module? As explained in the other reply in this thread, there is no need to complicate things. The relative path works just fine. Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Baby steps, Chris. Baby steps. :) I should have a set of patches out for modperl/t and A::TR::module2url shortly after a few more distclean/nmake tests. 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: [PATCH] Test TestRequest pod
Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=Chris
[PATCH] Apache::TestRequest::module2url
Here's the patch for Apache::TestRequest::module2url().
A set of patches to use it within the modperl tests is on it's way to
the dev list.
-=Chris
Index: lib/Apache/TestRequest.pm
===
--- lib/Apache/TestRequest.pm (revision 110069)
+++ lib/Apache/TestRequest.pm (working copy)
@@ -107,6 +107,23 @@
return $path;
}
+sub module2url {
+my $module = shift;
+my $opt = shift || {};
+my $scheme = $opt-{scheme} || 'http';
+my $path = $opt-{path} ||
+Apache::TestRequest::module2path($module);
+
+$path =~ s/^\///;
+
+Apache::TestRequest::module($module);
+
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+
+return $scheme://$hostport/$path;
+}
+
sub user_agent {
my $args = [EMAIL PROTECTED];
Re: [PATCH] Apache::TestRequest::module2url
Stas Bekman wrote: Christopher H. Laco wrote: Here's the patch for Apache::TestRequest::module2url(). A set of patches to use it within the modperl tests is on it's way to the dev list. Thanks Chris, committed with a few tweaks. Next it'd be nice to add a pod entries for this and module2path wrappers. As I have suggested earlier, if you have a patch that touches both modperl and a-t it's the best to send it together (even though svn's externals handling sucks and it won't show you 'svn diff' for the two at once, one needs to run those separately :( Oke dokie. I'll tackle the pod tomorrow. Thanks, -=Chris
Re: [PATCH] Test TestRequest pod
Christopher H. Laco wrote: Understood. What led me to contimplating those thoughts was the fact that some tests use hostport, and config, and a custom path, but just don't set A::TR::module. If it weren't for that, those test could be slimmed as well. That's when they use the default port. But that doesn't sound right, since they shouldn't need hostport/config and stuff. Where do you see such a test? Now I have to go searching again. :-) modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? I know there's a couple more lurkers in there, but maybe I'll stumble across those during another round of module2path-ing. -=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: [PATCH] Test TestRequest pod
Stas Bekman wrote: modperl/t/hooks/trans.t - does module2path, config, then hostport. No module, but does custom urls towards the end. You mean t/hooks/trans.t? sure it does: Apache::TestRequest::module($module); or are you talking about a different test? ANd so it does. On that note, I'm going to bed. :-/
Re: apxs calls on Win32
On Sun, 5 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
If apxs is installed on Win32, it is usually specified as a
.bat file. In querying apxs in apxs() of Apache::TestConfig,
however, Win32 needs both the path to cmd.exe (for running a
.bat command) and to Perl (in order to run apxs.bat) in
order to get something from
$val = qx($apxs -q $q 2$devnull);
This diff:
If it's only win32 case then +1 but if other platforms may have the same
problem, may be it's better to blindly launder $ENV{PATH} like we do in a
few other places (in which case there will be no need for this change, as
the right paths will be there already, correct?)
That's right - what about the following, copied from
the open_cmd sub of Apache::Build (for Win32, this needs
to use the ';' as the directory separator within $ENV{PATH},
rather than ':'.
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
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) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
=
--
best regards,
randy
Re: apxs calls on Win32
On Tue, 7 Dec 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
==
Index: lib/Apache/TestConfig.pm
===
--- lib/Apache/TestConfig.pm(revision 110064)
+++ lib/Apache/TestConfig.pm(working copy)
@@ -1043,7 +1043,8 @@
# Temporarily untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T disallows relative directories in the PATH
-$ENV{PATH} = join ':', grep !/^\./, split /:/, $ENV{PATH};
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
# launder for -T
$cmd = $1 if $cmd =~ /(.*)/;
@@ -1657,7 +1658,12 @@
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) };
+# Temporarily untaint PATH
+(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
+# -T disallows relative directories in the PATH
+my $sep = WIN32 ? ';' : ':';
+$ENV{PATH} = join $sep, grep !/^\./, split /$sep/, $ENV{PATH};
my $devnull = devnull();
my $apxs = shell_ready($self-{APXS});
$val = qx($apxs -q $q 2$devnull);
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!
OK, I'll do that - thanks!
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
--
best regards,
randy
Re: apxs calls on Win32
Also is there some File::Spec thingy that defines record
separator in paths?
I looked through there - there's not one specifically
defined. There are special cases for various platforms:
Mac = uses ',', but needs $ENV{Commands}, not $ENV{PATH}
OS2 = uses ';', but also translates '\' to '/'
VMS = uses a different $ENV variable
So some of these (eg, Mac and VMS) would require special
handling just to get at the equivalent of $ENV{PATH}.
Thanks for the research, Randy.
Is leaving it just as is OK for the moment (using ';' for
WIN32, ':' otherwise), and if someone has problems with it,
we can fix it then?
+1
Also, I haven't tried it yet, but just to make sure the
email messages go to the right place - can one do a commit
to Apache-Test from within modperl-2.0 svn (from within
the Apache-Test subdirectory)?
I think you can diff/ci only if you first cd into A-T dir. so it'll go to
the right list anyway. So there is no way you can commit the two at once I
think.
--
__
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: svn commit: r109866 - /httpd/httpd/trunk/modules/loggers/mod_log_config.c
On Dec 6, 2004, at 7:53 PM, Paul Querna wrote: I do not agree that using writev() would allow multiple children from scribbling over each other's log entries. I have not been able to cause this to happen on my local machines. You might want to consider what happens on all of the not so recent operating systems that run Apache, especially those that don't even implement writev. See what happens when APR_HAVE_WRITEV is not defined to 1. Roy
Re: mod_dumpio
On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote: On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote: Same location as mod_log_forensic? If you want to move them both into a modules/debug/ location, ++1. mod_bucketeer would be classified as a debugging module, also. It's currently under modules/test. Hmmm... maybe 'test' != 'debug' ?? ;)
Re: svn commit: r109866 - /httpd/httpd/trunk/modules/loggers/mod_log_config.c
On Mon, 6 Dec 2004, Paul Querna wrote: Having looked at the writev() implementation in FreeBSD 5.2, it will Not all platforms have writev(). I hope we stil have that APR flag for that ?! Dw
Re: mod_dumpio
On Dec 7, 2004, at 6:04 AM, Jim Jagielski wrote: On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote: On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote: Same location as mod_log_forensic? If you want to move them both into a modules/debug/ location, ++1. mod_bucketeer would be classified as a debugging module, also. It's currently under modules/test. Hmmm... maybe 'test' != 'debug' ?? ;) How about modules/dev and also move mod_example there? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: mod_dumpio
On Tue, 7 Dec 2004, Jim Jagielski wrote: On Dec 6, 2004, at 5:28 PM, Cliff Woolley wrote: On Mon, 6 Dec 2004, William A. Rowe, Jr. wrote: Same location as mod_log_forensic? If you want to move them both into a modules/debug/ location, ++1. mod_bucketeer would be classified as a debugging module, also. It's currently under modules/test. Hmmm... maybe 'test' != 'debug' ?? ;) Oh, no, I agree with you. I was saying that mod_bucketeer should be MOVED, not that mod_dumpio should go in modules/test/. :-)
Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
It appears that the patch for bug 18757 which disallows a
content-length header for all requests with a content-length of 0 is too
broad.
Index: D:/Projects/2.x/httpd-trunk/server/protocol.c
===
--- D:/Projects/2.x/httpd-trunk/server/protocol.c (revision
104639)
+++ D:/Projects/2.x/httpd-trunk/server/protocol.c (revision
104923)
@@ -1244,8 +1244,11 @@
*
* We can only set a C-L in the response header if we haven't
already
* sent any buckets on to the next output filter for this
request.
+ *
+ * Also check against cases of zero bytes sent, to avoid a bogus
+ * C-L on HEAD requests, or no-body GETs like 204s.
*/
-if (ctx-data_sent == 0 eos) {
+if (ctx-data_sent == 0 eos r-bytes_sent 0 ) {
ap_set_content_length(r, r-bytes_sent);
}
Property changes on: D:/Projects/2.x/httpd-trunk/server/protocol.c
___
Name: cvs2svn:cvs-rev
- 1.150
+ 1.151
The bug simply says that the content-length should be removed just for
HEAD requests. By removing it for all requests including an OPTIONS
requests, causes the SSL handshake to fail after a TLS upgrade (somebody
with more knowledge of SSL would have to explain why). According to the
bugzilla report, this patch didn't completely resolve the issue anyway.
I will be reverting the patch shortly unless somebody has a better fix.
Brad
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
On Tue, Dec 07, 2004 at 10:14:28AM -0700, Brad Nicholes wrote: It appears that the patch for bug 18757 which disallows a content-length header for all requests with a content-length of 0 is too broad. ... The bug simply says that the content-length should be removed just for HEAD requests. By removing it for all requests including an OPTIONS requests, causes the SSL handshake to fail after a TLS upgrade (somebody with more knowledge of SSL would have to explain why). According to the I tested the TLS upgrade stuff last week and it failed because the zero-length chunk to terminate the OPTIONS response was not sent through the mod_ssl output filter; is that the same problem you see? The problem was that r-connection-output_filters had been correctly adjusted to use the SSL output filter but r-output_filters had not, which looks purely like an issue in mod_ssl. joe bugzilla report, this patch didn't completely resolve the issue anyway. I will be reverting the patch shortly unless somebody has a better fix. Brad
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
I tested the TLS upgrade stuff last week and it failed because the
zero-length chunk to terminate the OPTIONS response was not sent
through
the mod_ssl output filter; is that the same problem you see?
I don't think so. I can make everything work again by simply allowing
the Content-Length: 0 header to be sent through. I'm not sure what
impact that header has on the rest of mod_ssl. Obviously by removing
it, it causes mod_ssl to *not* do something it was suppose to. My guess
is that if the zero-length chunk that terminates the OPTIONS response is
not being sent, it is probably a result of mod_ssl not seeing a
content-length header.
I think we are seeing the same problem. Before, a zero-length OPTIONS
response would be sent with t-e: chunked and a single
zero-terminator-chunk. The 0\r\n\r\n packet was being sent unencrypted
and breaking the SSL connection. After you reverted the protocol.c
change, a zero-length OPTIONS response is sent with C-L: 0 and hence
terminates after the headers. Subsequent requests on the connection get
the right filter stack.
So you have successfully hidden the mod_ssl bug for upgrades with
zero-length responses. The fact that mod_ssl (incorrectly) refuses to
upgrade anything other than an OPTIONS request makes the bug less
obvious since OPTIONS responses are rarely anything but zero-length, but
I'll fix that.
For an upgrade on GET the strace now looks like:
send(3, GET / HTTP/1.1\r\nHost..., 173, 0) = 173
recv(3, HTTP/1.1 101 Switchi..., 4096, 0) = 85
read(4, *J\204\17\342g l\327U\323/\271..., 32) = 32
write(3, \200|\1\3\1\0c\0\0\0\20\0\0009..., 126) = 126
SSL negotiation and response headers
read(3, \26\3\1\, 5) = 5
read(3, a\20\363\37{\372\347\205\350\36..., 48) = 48
read(3, html, 5) = 5
^ uh-oh!
BTW, what are you using to test TLS Upgrade with?
A hacked up version of neon.
yet another autoconf horrow story (Problem w/ apache-2.0.52 + php-4.3.9: unresolved symbol ap_loaded_modules)
After days end days of debugging the undebuggable (=autoshit), i've found out, that configure doens't recognize my GNU ld as an GNU ld and so disables shared libraries silently. This ended up in libtool generating only static libraries instead of shared objects. Passing --with-gnu-ld didn't have any little influence on that. I've trashed it to use $EGREP (which was detected properly) and now evryting works fine: .so's are created and third-party modules (ie php4) can be loaded properly. This dawm autoshit again has costed three days of work for me. And still it has dozens of problems (ie apxs is completely unsusable for sysroot builds) We really, really go away from it. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
[PATCH] fixing broken gnu ld (mis)detection problem
Hi folks,
here's a patch against httpd-2.0.49 which fixes the broken
configure script. I'm happy enough that I now have at least *one*
working version and I'm relly too lazy to go in deeper autoconf
torture, so the one who's responsible for ./configure should
fix it all versions.
Life could be so easy without autoshit!
cu
--
-
Enrico Weigelt== metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: [EMAIL PROTECTED]
cellphone: +49 174 7066481
-
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-
diff -ruN httpd-2.0.49.orig/srclib/apr/configure
httpd-2.0.49/srclib/apr/configure
--- httpd-2.0.49.orig/srclib/apr/configure Tue Dec 7 21:28:31 2004
+++ httpd-2.0.49/srclib/apr/configure Tue Dec 7 21:31:04 2004
@@ -7858,7 +7858,7 @@
# Check to see if the program is GNU ld. I'd rather use --version,
# but apparently some GNU ld's only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
- if $lt_cv_path_LD -v 21 /dev/null | egrep '(GNU|with BFD)'
/dev/null; then
+ if $lt_cv_path_LD -v 21 /dev/null | $EGREP '(GNU|with BFD)'
/dev/null; then
test $with_gnu_ld != no break
else
test $with_gnu_ld != yes break
@@ -7888,7 +7888,7 @@
echo $ECHO_N (cached) $ECHO_C 6
else
# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 21 /dev/null | egrep '(GNU|with BFD)' 15; then
+if $LD -v 21 /dev/null | $EGREP '(GNU|with BFD)' 15; then
lt_cv_prog_gnu_ld=yes
else
lt_cv_prog_gnu_ld=no
@@ -7929,10 +7929,10 @@
# Adding the `sed 1q' prevents false positives on HP-UX, which says:
# nm: unknown option B ignored
# Tru64's nm complains that /dev/null is an invalid object file
- if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | egrep
'(/dev/null|Invalid file or object type)' /dev/null; then
+ if ($tmp_nm -B /dev/null 21 | sed '1q'; exit 0) | $EGREP
'(/dev/null|Invalid file or object type)' /dev/null; then
lt_cv_path_NM=$tmp_nm -B
break
- elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | egrep /dev/null
/dev/null; then
+ elif ($tmp_nm -p /dev/null 21 | sed '1q'; exit 0) | $EGREP /dev/null
/dev/null; then
lt_cv_path_NM=$tmp_nm -p
break
else
@@ -8003,7 +8003,7 @@
_count=0
echo ${ECHO_N-$ac_n} 0123456789${ECHO_C-$ac_c} $tmp/sed.in
# Check for GNU sed and select it if it is found.
-if ${_sed} --version 21 /dev/null | egrep '(GNU)' /dev/null; then
+if ${_sed} --version 21 /dev/null | $EGREP '(GNU)' /dev/null; then
lt_cv_path_SED=${_sed}
break
fi
@@ -8287,7 +8287,7 @@
esac
# If we're using GNU nm, then use its standard symbol codes.
-if $NM -V 21 | egrep '(GNU|with BFD)' /dev/null; then
+if $NM -V 21 | $EGREP '(GNU|with BFD)' /dev/null; then
symcode='[ABCDGISTW]'
fi
@@ -8332,8 +8332,8 @@
fi
# Make sure that we snagged all the symbols we need.
- if egrep ' nm_test_var$' $nlist /dev/null; then
- if egrep ' nm_test_func$' $nlist /dev/null; then
+ if $EGREP ' nm_test_var$' $nlist /dev/null; then
+ if $EGREP ' nm_test_func$' $nlist /dev/null; then
cat EOF conftest.$ac_ext
#ifdef __cplusplus
extern C {
@@ -8610,7 +8610,7 @@
file_magic_regex=`expr \$deplibs_check_method\ : \file_magic
\(.*\)\`
MAGIC_CMD=$lt_cv_path_MAGIC_CMD
if eval $file_magic_cmd \$file_magic_test_file 2 /dev/null |
- egrep $file_magic_regex /dev/null; then
+ $EGREP $file_magic_regex /dev/null; then
:
else
cat EOF 12
@@ -8674,7 +8674,7 @@
file_magic_regex=`expr \$deplibs_check_method\ : \file_magic
\(.*\)\`
MAGIC_CMD=$lt_cv_path_MAGIC_CMD
if eval $file_magic_cmd \$file_magic_test_file 2 /dev/null |
- egrep $file_magic_regex /dev/null; then
+ $EGREP $file_magic_regex /dev/null; then
:
else
cat EOF 12
@@ -9361,7 +9361,7 @@
if test -n $lt_cv_prog_cc_shlib; then
{ echo $as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to
build shared libraries 5
echo $as_me: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared
libraries 2;}
- if echo $old_CC $old_CFLAGS | egrep -e [ ]$lt_cv_prog_cc_shlib[
] /dev/null; then :
+ if echo $old_CC $old_CFLAGS | $EGREP -e []$lt_cv_prog_cc_shlib[
] /dev/null; then :
else
{ echo $as_me:$LINENO: WARNING: add \`$lt_cv_prog_cc_shlib' to the CC or
CFLAGS env variable and reconfigure 5
echo $as_me: WARNING: add \`$lt_cv_prog_cc_shlib' to the CC or CFLAGS env
variable and reconfigure 2;}
@@
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
So what are you suggesting that the appropriate fix should be? Even
though the protocol.c patch was bogus, it sounds like might have exposed
something else. In fact I am still not seeing where the problem is.
The protocol.c patch was just allowing a bad response to happen that
should never have happened in the first place. It seems like the
appropriate OPTIONS response should include C-L:0. Anything else that
actually has content would also contain the appropriate C-L: header.
Brad
[EMAIL PROTECTED] Tuesday, December 07, 2004 12:51:15 PM
On Tue, Dec 07, 2004 at 11:01:13AM -0700, Brad Nicholes wrote:
I tested the TLS upgrade stuff last week and it failed because the
zero-length chunk to terminate the OPTIONS response was not sent
through
the mod_ssl output filter; is that the same problem you see?
I don't think so. I can make everything work again by simply
allowing
the Content-Length: 0 header to be sent through. I'm not sure
what
impact that header has on the rest of mod_ssl. Obviously by
removing
it, it causes mod_ssl to *not* do something it was suppose to. My
guess
is that if the zero-length chunk that terminates the OPTIONS response
is
not being sent, it is probably a result of mod_ssl not seeing a
content-length header.
I think we are seeing the same problem. Before, a zero-length OPTIONS
response would be sent with t-e: chunked and a single
zero-terminator-chunk. The 0\r\n\r\n packet was being sent
unencrypted
and breaking the SSL connection. After you reverted the protocol.c
change, a zero-length OPTIONS response is sent with C-L: 0 and hence
terminates after the headers. Subsequent requests on the connection
get
the right filter stack.
So you have successfully hidden the mod_ssl bug for upgrades with
zero-length responses. The fact that mod_ssl (incorrectly) refuses to
upgrade anything other than an OPTIONS request makes the bug less
obvious since OPTIONS responses are rarely anything but zero-length,
but
I'll fix that.
For an upgrade on GET the strace now looks like:
send(3, GET / HTTP/1.1\r\nHost..., 173, 0) = 173
recv(3, HTTP/1.1 101 Switchi..., 4096, 0) = 85
read(4, *J\204\17\342g l\327U\323/\271..., 32) = 32
write(3, \200|\1\3\1\0c\0\0\0\20\0\0009..., 126) = 126
SSL negotiation and response headers
read(3, \26\3\1\, 5) = 5
read(3, a\20\363\37{\372\347\205\350\36..., 48) = 48
read(3, html, 5) = 5
^ uh-oh!
BTW, what are you using to test TLS Upgrade with?
A hacked up version of neon.
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
On Tue, Dec 07, 2004 at 03:00:52PM -0700, Brad Nicholes wrote: So what are you suggesting that the appropriate fix should be? Even though the protocol.c patch was bogus, it sounds like might have exposed something else. In fact I am still not seeing where the problem is. Try doing an upgrade on any request where the response includes an entity. I originally tried modifying ssl_io_filter_init and upwards to take an optional request_rec * and pass that to ap_add_output_filter but this broke everything horribly. Possibly I just missed some subtlety but if that's fatally flawed I have no better ideas. joe
Re: Patch for bug 18757 breaks TLS upgrade - [Content-Length is removed from HEAD requests]
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? Brad [EMAIL PROTECTED] Tuesday, December 07, 2004 4:18:13 PM On Tue, Dec 07, 2004 at 03:00:52PM -0700, Brad Nicholes wrote: So what are you suggesting that the appropriate fix should be? Even though the protocol.c patch was bogus, it sounds like might have exposed something else. In fact I am still not seeing where the problem is. Try doing an upgrade on any request where the response includes an entity. I originally tried modifying ssl_io_filter_init and upwards to take an optional request_rec * and pass that to ap_add_output_filter but this broke everything horribly. Possibly I just missed some subtlety but if that's fatally flawed I have no better ideas. joe
