httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the DocumentRoot (e.g.,
Hi,
I just discovered flood, and I'm interested in writing my own report
based on the raw output. The only documentation I can find is here:
http://cvs.apache.org/viewcvs.cgi/httpd-test/flood/docs/docbook/
flood.xml?rev=1.8view=markup
Last updated on April 15, 2004, where it says at the
-BEGIN PGP SIGNED MESSAGE-
Rodent of Unusual Size wrote:
httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]
Well, bugger. This moved to subversion and I didn't notice; these
have been coming from the old CVS. Fixed
flood STATUS: -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]
Release:
1.0: Released July 23, 2002
milestone-03: Tagged January 16, 2002
ASF-transfer: Released July 17, 2001
As you can see from the email below, some modules embed a version number
in the module 'mod_fastcgi-2.4.2-AP20.dll'. Our should_skip_module only
matches an exact name. The patch at the end of this email extends the
functionality to support regex skip arguments. Let me know if you have any
Stas Bekman wrote:
As you can see from the email below, some modules embed a version number
in the module 'mod_fastcgi-2.4.2-AP20.dll'. Our should_skip_module only
matches an exact name. The patch at the end of this email extends the
functionality to support regex skip arguments. Let me know
The uploaded file
Apache-Test-1.19.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GO/GOZER/Apache-Test-1.19.tar.gz
size: 142015 bytes
md5: 795c1fcefd0f21b126f573fc46427139
Changes since 1.18:
Test for module.c instead of module.so for IfModule in
find_and_load_module [Chia-Liang
This is missing something related to %d...
#ifdef DEBUGGING
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
proxy: CONNECT: read %d from client,
);
#endif
--
Andreas Steinmetz SPAMmers use [EMAIL
I guess I am still a little unclear on what the advantage is to using
ldap:// + start_tls vs. ldaps://. The end result is the same except
that you have a secure connection to the LDAP server on 389 rather than
636. Is that the only reason? Administrators don't want to open a
dedicated SSL
At 10:12 AM 1/6/2005, Brad Nicholes wrote:
I guess I am still a little unclear on what the advantage is
to using ldap:// + start_tls vs. ldaps://. The end result
is the same except that you have a secure connection to the LDAP
server on 389 rather than 636. Is that the only reason?
Regarding LDAP, Apache is a client which must adhere to how
the LDAP server is configured, be that a secure port (ldaps://)
or via an unsecure connection (ldap://) that can be upgraded with
a StartTLS. It appears, from the OpenLdap perspective, that
use of ldaps:// is depricated in favor of
Bennett, Tony - CNF wrote:
Regarding LDAP, Apache is a client which must adhere to how
the LDAP server is configured, be that a secure port (ldaps://)
or via an unsecure connection (ldap://) that can be upgraded with
a StartTLS. It appears, from the OpenLdap perspective, that
use of ldaps:// is
Brad Nicholes wrote:
I guess I am still a little unclear on what the advantage is to using
ldap:// + start_tls vs. ldaps://. The end result is the same except
that you have a secure connection to the LDAP server on 389 rather than
636. Is that the only reason?
Apparently ldap:// + STARTTLS
At 03:18 PM 1/6/2005, Graham Leggett wrote:
Brad Nicholes wrote:
I guess I am still a little unclear on what the advantage is to using
ldap:// + start_tls vs. ldaps://. The end result is the same except
that you have a secure connection to the LDAP server on 389 rather than
636. Is that
I personally feel more comfortable having LDAP on an SSL port only,
then
I know there is no way my server can be accessed accidently without
encryption in place.
Call me paranoid, but I completely agree. Especially since the primary
purpose of auth_ldap is authentication, ie. userid's and
At 05:19 PM 1/6/2005, Brad Nicholes wrote:
This doesn't mean that APR-util doesn't support the concept of
starting
and stopping tls, it only means that util_ldap doesn't choose to use
this option.
So we should probably split start_tls out from apr_ldap_ssl_init() into
it's own API. This way
Off the top of my head, performance. Maybe you really only need a
secure connection during the bind but after that switching back to an
unsecure connection would perform better. Maybe you want to hold a
connection pool of LDAP connections that can be used to transfer
sensitive information or
Hey Will,
I do indeed think that this patch is useful and I would like to apply
it to my configuration! Alas I am not all that good with the
modification/patching of programs using the source code (I only know
how to program in Visual Basic... which I am hoping to ditch and learn
C++) or the use
18 matches
Mail list logo
