Is this really a bug in httpd, or is it a bug in the test? I think it's a
bug in the test that only shows up days 1-9 of the month, but I just
thought I'd check before I went and 'fixed' the test.
# testing : TIME_YEAR
# expected: '2001'
# received: '2001'
ok 15
# testing : TIME_MON
# expected:
prep_walk_cache(), used to initialize a cache within
(directory|file|location)_walk, is one of the most
time-consuming non-syscall functions in 2.0 at present.
60% of prep_walk_cache()'s run time is spent in
apr_pool_userdata_get() and apr_pool_userdata_setn().
We've tuned the hash table code
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 4:14 AM
Now I begin to wonder, if we created a fast_redirect method for mod_negotation,
why on earth shouldn't mod_dir follow the same convention?
Here's a patch - heavily refactored. It merits discussion. I
Note: given the role of this function in keeping requests inside the
document root, I've tested this new code against the standard boundary
cases like /./../foo and /foo/../../bar. If anyone has specific
additional test cases or points of concern, though, please let me know.
Thanks,
--Brian
How do i get out of it! :)
Read your messages headers [on any well behaved list.]
Should be some header like;
list-unsubscribe: mailto:[EMAIL PROTECTED]
if that helps. [a blank message works fine, or you could write a 200
line note. Doesn't matter to the mail list engine.]
Bill
- Original Message -
From:
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 4:14 AM
Now I begin to wonder, if we created a fast_redirect method for mod_negotation,
why on earth shouldn't mod_dir follow the same convention?
Following this little experiment one step further, I've come to
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 9:31 PM
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Sunday, December 02, 2001 4:14 AM
Now I begin to wonder, if we created a fast_redirect method for mod_negotation,
why on earth shouldn't mod_dir
Is anybody out there working on a resolution of PR 7492? The bug
is basically that, when you use Listen *, it listens only on IPv6
interfaces, and never opens any of the IPv4 interfaces in the system.
(This may actually work to listen on IPv4 interfaces on some systems, but
not all systems
