Asst'd Win32 failures [that should simply be skipped]
The following tests are all sh scripts that won't work on win32, we should exclude on non-sh supporting platforms; apache\acceptpathinfo.t 36 10 27.78% 9-10, 21-24, 33-36 The following test looks like we didn't follow our have apxs test results (we can't compile modules on win32 right at this instant) before we try an echo_post_chunk request; apache\chunkinput.t92 22.22% 2-3 This looks like the same problem again, we never built echo_post before attempting to run the contentlength.t tests; apache\contentlength.t203 15.00% 2, 6, 10 I'm entirely unclear what is happening on these two tests, however; apache\limits.t 102 20.00% 9-10 # Testing LimitRequestBody; should fail # Chunked transfer-encoding enabled # testing : Test #9 # expected: 413 # received: 500 not ok 9 # Failed test 9 in apache\limits.t at line 112 fail #2 # Server response: # 500 (Internal Server Error) EOF # Client-Date: Sat, 22 Jun 2002 20:47:14 GMT # # # # Testing LimitRequestBody; should fail # Chunked transfer-encoding disabled #lwp request: #GET http://localhost:8529/apache/limits/ HTTP/1.0 #User-Agent: libwww-perl/5.65 #Content-Type: text/plain #X-Subtest: 10 # #aaa[...sparing you lots of 'a's in the lwp=2 output... a #server response: #500 (Internal Server Error) EOF instead of reponse status line #Content-Length: 0 #Client-Date: Sat, 22 Jun 2002 20:47:14 GMT #X-Content-Length-Note: added by Apache::TestRequest # # # testing : Test #10 # expected: 413 # received: 500 not ok 10 # Failed test 10 in apache\limits.t at line 123 fail #2 # Server response: # 500 (Internal Server Error) EOF instead of reponse status line # Content-Length: 0 # Client-Date: Sat, 22 Jun 2002 20:47:14 GMT # X-Content-Length-Note: added by Apache::TestRequest This one is just plain silly, looks like a semantics error... modules\include.t 516 11.76% 46-51 ok 36 ok 37 # Skipping XBitHack tests on this platform ok 38 # Skipping XBitHack tests on this platform ok 39 # Skipping XBitHack tests on this platform ok 40 # Skipping XBitHack tests on this platform ok 41 # Skipping XBitHack tests on this platform ok 42 # Skipping XBitHack tests on this platform ok 43 # Skipping XBitHack tests on this platform ok 44 # Skipping XBitHack tests on this platform ok 45 # Skipping XBitHack tests on this platform FAILED tests 46-51 Failed 6/51 tests, 88.24% okay (-9 skipped tests: 36 okay, 70.59%) Since when is a skip == failure :-? I won't bother reporting our failures in ssl\*.t for the moment till I get a handle on what ssl perl module errors are going on. So if someone who groks this all would add [and fix the existing borked] 'skipping' statuses to these tests, or share some observation about what is up with the limits.t test, I would be most appreciative. Bill
Re: Asst'd Win32 failures [that should simply be skipped]
On Sat, 22 Jun 2002, William A. Rowe, Jr. wrote:
This one is just plain silly, looks like a semantics error...
modules\include.t 516 11.76% 46-51
ok 36
ok 37 # Skipping XBitHack tests on this platform
ok 38 # Skipping XBitHack tests on this platform
ok 39 # Skipping XBitHack tests on this platform
ok 40 # Skipping XBitHack tests on this platform
ok 41 # Skipping XBitHack tests on this platform
ok 42 # Skipping XBitHack tests on this platform
ok 43 # Skipping XBitHack tests on this platform
ok 44 # Skipping XBitHack tests on this platform
ok 45 # Skipping XBitHack tests on this platform
FAILED tests 46-51
Failed 6/51 tests, 88.24% okay (-9 skipped tests: 36 okay, 70.59%)
Since when is a skip == failure :-?
The following
===
Index: t/modules/include.t
===
RCS file: /home/cvspublic/httpd-test/perl-framework/t/modules/include.t,v
retrieving revision 1.21
diff -u -r1.21 include.t
--- t/modules/include.t 20 Jun 2002 04:05:04 - 1.21
+++ t/modules/include.t 22 Jun 2002 21:31:00 -
@@ -141,9 +141,9 @@
for (1..9) {
skip Skipping XBitHack tests on this platform, 1;
}
-exit;
+#exit;
}
-
+else {
### XBITHACK TESTS
# test xbithack off
$doc = xbithack/off/test.html;
@@ -189,7 +189,7 @@
XBitHack full [0554]
);
-
+}
### MOD_BUCKETEER+MOD_INCLUDE TESTS
# we can use mod_bucketeer to create edge conditions for mod_include, since
# it allows us to create bucket and brigade boundaries wherever we want
===
is one way of fixing this.
best regards,
randy kobes
Re: daedalus pegged
Greg Ames [EMAIL PROTECTED] wrote: Cliff Woolley wrote: Well, I guess our security advisory worked. Daedalus is totally maxxed out at 700 concurrent requests holy cripe! (which I assume is the maxclients setting). yep. MANY people downloading the new releases of Apache (expecially 1.3.26.tar.gz and the win32 binary of the same version). Good to see our efforts taken seriously. It's back down to 560 now. We've got a bunch of headroom available on MaxClients, but I don't want to bump it up a huge amount at times like this without watching it closely. Thanks for the heads up. I'm rsyincing now the distribution over onto nagoya... Given it's an *.apache.org machine, I believe that people might feel more safe to download it from there... I'm adding a mirror to our set... One other thing we might want to consider is putting a link to the download site over onto the httpd site, pointing to /dist, with something like A href=httpd://www.apache.org/dist/httpdUpdate NOW!/A Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]
Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
Looking for both faults (passing the next filter when we are doing lookups, and passing NULL when we are going to serve the content) ... it really seems that; D:\clean\httpd-2.0\modules\mappers\mod_negotiation.c(2550): sub_req = ap_sub_req_lookup_file(variant-file_name, r, NULL); SHOULD be setting the next filter. Anyone want to dig on this? Bill wrowe 2002/06/22 09:32:45 Modified:include http_request.h modules/generators mod_cgi.c mod_cgid.c Log: Note the changed meaning of the NULL next_filter argument to the ap_sub_req_lookup() family, and fix a few oddball cases (those are, PATH_TRANSLATED reference issues.)
RE: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 22, 2002 9:45 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: httpd-2.0/modules/generators mod_cgi.c mod_cgid.c Looking for both faults (passing the next filter when we are doing lookups, and passing NULL when we are going to serve the content) ... it really seems that; D:\clean\httpd-2.0\modules\mappers\mod_negotiation.c(2550): sub_req = ap_sub_req_lookup_file(variant-file_name, r, NULL); SHOULD be setting the next filter. Anyone want to dig on this? I am missing something. The third argument has nothing to do with whether the request will be served. It has to do with how the filter stack is initialized in the sub-request. If the argument is NULL, the sub-requests filters are set to the protocol filters of the original request. If the argument isn't NULL, then the sub-request's filters are initialized to the filter passed in. In either case, the data can either be sent or not. Please revert the doc portions of your last change, they are incorrect. The code is safe to leave, because the requests aren't actually served. However, mod_negotiation is 100% correct, and should NOT be changed. Ryan Bill wrowe 2002/06/22 09:32:45 Modified:include http_request.h modules/generators mod_cgi.c mod_cgid.c Log: Note the changed meaning of the NULL next_filter argument to the ap_sub_req_lookup() family, and fix a few oddball cases (those are, PATH_TRANSLATED reference issues.)
worker MPM shutdown
During the worker MPM non-graceful shutdown, the signal_threads() function attempts to close all open sockets. I have two major objections to this: 1) It's not necessarily safe to close a socket that another thread is using. Note that apr_socket_close() calls the pool cleanup on the pool from which the socket was allocated--bad news if one of the active worker threads happens to be, say, registering a new cleanup in the same pool at the same time. 2) It appears to be contributing to the fact that non-graceful shutdown doesn't work. Without the socket shutdown loop, the child processes shut down promptly. As I understand it, the motivation for closing the sockets during shutdown was to try to fix a race condition in which an active worker thread might be trying to write to a socket at the same time that the underlying pool was being destroyed (due to the recursive destruction of APR's global_pool during apr_terminate()). If so, I think the right solution is to add a way to create parentless pools that aren't implicitly added as children to the global pool, so that a worker thread's pool won't disappear before that thread does. Is there any specific reason why we're not doing this already? Thanks, --Brian
BUG: http_vhost.c:fix_hostname
There is a bug in fix_hostname. The comment above function says that the hostname
is lowercased, but it's not.
the line which reads:
*dst++ = *src++;
in context of:
goto bad;
else
break;
}
*dst++ = *src++;
}
/* strip trailing gubbins */
if (dst host dst[-1] == '.') {
dst[-1] = '\0';
} else {
should read:
*dst++ = tolower(*src++);
Thanks,
--Perry
--
Perry Harrington Director ofzelur xuniL ()
perry at webcom dot com System ArchitectureThink Blue. /\
Those who would give up essential liberty to purchase a little temporary safety
deserve neither liberty or safety. Nor, are they likely to end up with either.
-- Benjamin Franklin
