On Tue, Jan 04, 2005 at 02:35:25PM -0500, Jeff Trawick wrote:
does this look correct?
svn copy https://svn.apache.org/repos/asf/httpd/httpd/trunk \
https://svn.apache.org/repos/asf/httpd/httpd/branches/proxy-reqbody
Yup. -- justin
William A. Rowe, Jr. said:
The correct scheme/port for STARTTLS LDAP connections is
ldap:// with port 389 implicit. We need a mechanism to clarify
to mod_ldap that TLS security is desired.
I have just taught's apr-utils' apr_ldap_init() function to handle
STARTTLS in addition to SSL (or no
keeps getting bounced. Sorry for breaking thread.
Original Message
Subject: Re: How to change ap_document_root variable from a apache2
Paul Querna wrote:
It is impossible with the current way virtual hosts and document roots
There may be some benefit to having a virtual host
Jeff Trawick wrote:
On 4 Jan 2005 09:58:09 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jfclere
Date: Tue Jan 4 01:58:01 2005
New Revision: 124080
URL: http://svn.apache.org/viewcvs?view=revrev=124080
Log:
Add including of util_charset.h otherwise ap_hdrs_from_ascii is not defined.
At 01:07 AM 1/5/2005, [EMAIL PROTECTED] wrote:
Author: minfrin
Date: Tue Jan 4 23:07:46 2005
New Revision: 124187
URL: http://svn.apache.org/viewcvs?view=revrev=124187
Log:
Fix some compiler warnings inside the LDAP modules
--- httpd/httpd/trunk/modules/ldap/util_ldap.c (original)
+++
This ancient bug;
http://archive.apache.org/gnats/73
was addressed very early in httpd-2.0 However - it makes very
detailed error logs almost impossible to read(!)
When I run a mod_aspdotnet debug build at loglevel debug, the
module spews out over 100 lines per request. To have , referrer:
On Thu, Dec 30, 2004 at 09:23:39PM +, Nick Kew wrote:
On Thu, 30 Dec 2004, Dick Snippe wrote:
cachable pages. Prior to apache 2.0.50 this wasn't a very big issue; these
pages would be cached, many people would be using the same cookie and that
was that. However, after apache-2.0.50
I'm running a site that uses mod_unique_id to generate session IDs
under Apache 1.3. We'd like to later be able to use the session IDs
as database keys, but at our volume (a hundred million sessions per
day) using non-numerics as keys makes databases painfully slow. We
tried a scheme where we
