At 11:51 PM 5/10/2005, André Malo wrote:
. builds and the old tid:time:pid format is good still on unix.
What happend to the good ol' RTC?
shrug happy to revert it. mod_log_forensic certainly isn't in
the --modules-most list - and was a typical example of an explicitly
thread-unsafe module.
I'd like to modify the Win32 build projects (of mod_jk, and
httpd 1.3/2.0/2.1-dev, along with apr);
The /O2 optimization option is extremely agressive, unfortunately
it produces less than ideal crash traceback information. That
is due to the (implicit) /Oy flag, which omits respecible stack
The subject is misleading; we do allow keepalives on any bogus
requests, today. Undoubtedly this is already used in the wild.
Attached is a patch that would drop keepalive for the garbage
requests that never even hit mod_forensics, or any other module,
due to bogus request lines or unparseable
In mod_ssl.h, BOOL
is defined as "unsigned
int".
Some mod_ssl parameters are defined as BOOL:
struct SSLSrvConfigRec
{ SSLModConfigRec
*mc; BOOL
enabled; BOOL
proxy_enabled; const
char *vhost_id;
int
vhost_id_len;
int
session_cache_timeout;
modssl_ctx_t *server;
On 5/2/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 5/2/05, Rici Lake [EMAIL PROTECTED] wrote:
If the action is required to compensate for a browser bug, wouldn't it
be better to leave it as an environment variable and set it with
BrowserMatch?
You're absolutely right. I put the
William A. Rowe, Jr. wrote:
I'd like to modify the Win32 build projects (of mod_jk, and
httpd 1.3/2.0/2.1-dev, along with apr);
The /O2 optimization option is extremely agressive, unfortunately
it produces less than ideal crash traceback information. That
is due to the (implicit) /Oy flag,
This is a patch for the version of ab on the trunk.
In this version of ab, HAVE_OPENSSL controls if I
have OpenSSL. I conformed to the way although I
did not checked the case of HAVE_SSLC.
There has also been small more fixes.
1. The resulting shared key bit length is now the
number of
On Tue, 10 May 2005 23:36:57 -, [EMAIL PROTECTED] wrote:
[...]
+const char * get_forensic_id(pool *p)
+{
+static APACHE_TLS next_id = 0;
+
+/* we make the assumption that we can't go through all the PIDs in
+ under 1 second */
+#ifdef MULTITHREAD
+return ap_psprintf(p,
This is a second patch to ab in 2.0.54 package.
It fixes the things below against the first patch.
1. The resulting shared key bit length is now the
number of effective bits.
2. Now ab does not dump core in case of SSL handshake
error.
--
Masaoki Kobayashi
[EMAIL PROTECTED]
--- ab.c.org
On 5/11/05, Jeff Trawick [EMAIL PROTECTED] wrote:
Funny. I just heard from a Japanese user with an issue with this path
too, but this time with 2.0. A third-party module is generating a
custom error response and specifies a Japanese codepage in the
generated HTML. But it goes through this
VC.NET 2005 (still in Beta 5) has much more optimizations (global nes at
link time).
Maybe it would be better to go directly to it, no ?
- Original Message -
From: Branko ibej [EMAIL PROTECTED]
To: William A. Rowe, Jr. [EMAIL PROTECTED]
Cc: dev@httpd.apache.org; Tomcat Developers List
At 08:39 AM 5/11/2005, Brian Havard wrote:
On Tue, 10 May 2005 23:36:57 -, [EMAIL PROTECTED] wrote:
+#ifdef MULTITHREAD
+return ap_psprintf(p, %x:%lx:%x, getpid(), time(NULL), next_id++);
+#else
+return ap_psprintf(p, %x:%x:%lx:%x, getpid(), gettid(), time(NULL),
next_id++);
+#endif
[EMAIL PROTECTED] wrote:
VC.NET 2005 (still in Beta 5)
still in beta...
has much more optimizations (global nes at link time).
Maybe it would be better to go directly to it, no ?
99% of the work of moving from MSVC6 to any flavour of VC.Net is in
converting the project files. So it doesn't matter
William A. Rowe, Jr. wrote:
I'd like to modify the Win32 build projects (of mod_jk, and
httpd 1.3/2.0/2.1-dev, along with apr);
The /O2 optimization option is extremely agressive, unfortunately
it produces less than ideal crash traceback information. That
is due to the (implicit) /Oy flag,
William A. Rowe, Jr. wrote:
At 08:46 AM 5/11/2005, Branko ibej wrote:
All in all - comments?
How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least.
Not for 1.3 or 2.0 httpd - you lose some measure of binary
compatibility. We can jump through hoops
At 08:46 AM 5/11/2005, Branko Čibej wrote:
All in all - comments?
How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it?
It's time, to say the least.
Not for 1.3 or 2.0 httpd - you lose some measure of binary
compatibility. We can jump through hoops to continue to use
the
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening right now with Subversion. The Python 2.4 distro
is built with VS.NET (2003, I
At 04:35 PM 5/11/2005, Branko Čibej wrote:
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening right now with Subversion. The Python 2.4
William A. Rowe, Jr. wrote:
At 04:35 PM 5/11/2005, Branko ibej wrote:
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening
Hello all,
I have a change which implements a generic function comparing returned code
against specified as an attribute of the url. The diff is enclosed. Is there
a document how to check-in into the flood source tree?
Yup. It is actually for httpd-dev folks, but most rules apply anyway:
[EMAIL PROTECTED] wrote:
Author: bnicholes
Date: Wed May 11 15:34:18 2005
New Revision: 169705
URL: http://svn.apache.org/viewcvs?rev=169705view=rev
Log:
Add the LDAPVerifyServerCert directive to util_ldap to force
verification of a server certificate when establishing an SSL connection
Paul Querna wrote:
[EMAIL PROTECTED] wrote:
Author: bnicholes
Date: Wed May 11 15:34:18 2005
New Revision: 169705
URL: http://svn.apache.org/viewcvs?rev=169705view=rev
Log:
Add the LDAPVerifyServerCert directive to util_ldap to force
verification of a server certificate when establishing an SSL
Sander Striker wrote:
Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0?
Yes. We could do the branch...
Heck, you don't even need to revert the commit to do that, just branch
from the revision before the change was made to trunk...
-garrett
Quoting Bojan Smojver [EMAIL PROTECTED]:
Quoting [EMAIL PROTECTED]:
libapreq2-2.05-dev Released
I will make libapreq2 and accompanying (e.g. mod_perl 2.0.0-RC6) RPMS
for Fedora Core 3 available in the next day or so.
The (untested) RPMS are here:
ftp://ftp.rexursive.com/pub/libapreq2/
You will
Sorry, wasn't thinking about apr-util 1.1.x compatibility. Which would you
rather see happen, revert or branch without this change? How soon are we going
to see apr-util 1.2? Without this directive, certificate verification is at
the mercy of the global ldap setting.
Brad
[EMAIL
At 05:52 PM 5/11/2005, Paul Querna wrote:
I believe we should uphold the policy of using only released versions of
a dependency.
+1, however...
I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could
still use more love.
Why not? Looks like apr_dbd should simply be pushed off
Is there an issue with backporting this change to 1.1.x branch and releasing a
apr-util 1.1.3?
Brad
[EMAIL PROTECTED] Wednesday, May 11, 2005 5:28:19 PM
At 05:52 PM 5/11/2005, Paul Querna wrote:
I believe we should uphold the policy of using only released versions of
a dependency.
+1,
Brad Nicholes wrote:
Is there an issue with backporting this change to 1.1.x branch
and releasing a apr-util 1.1.3?
Yes, According to APR's versioning policy:
http://apr.apache.org/versioning.html
Versions are denoted using a standard triplet of integers:
MAJOR.MINOR.PATCH. The basic intent
At 06:43 PM 5/11/2005, Brad Nicholes wrote:
Is there an issue with backporting this change to 1.1.x branch and releasing a
apr-util 1.1.3?
Yes, IIUC we don't add API features on the subversion bumps,
only on minor version bumps. So this new option triggers
an automatic minor bump to 1.2.0 (so
So I guess I am confused. Are you saying that we *can* release 1.2 or am I
stuck with putting LDAP SDK #ifdef code back in util_ldap in order to fix this
problem?
Brad
[EMAIL PROTECTED] Wednesday, May 11, 2005 5:56 PM
Brad Nicholes wrote:
Is there an issue with backporting this change to
Brad Nicholes wrote:
So I guess I am confused. Are you saying that we *can* release 1.2 or
am I stuck with putting LDAP SDK #ifdef code back in util_ldap in
order to fix this problem?
I am saying we can release APR-Util 1.2 -- but that discussion belongs
on apr-dev.
I think the best solution
On Thu, 12 May 2005, Branko ^Libej wrote:
William A. Rowe, Jr. wrote:
[ ... ]
Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR
0.9 / etc all in the same 'generation' of code.
Do you want the ASF to be a leader of this 'breakage' as
the Python project was? This is why the push
Based on the results from the '[PROPOSAL] Branch 2.1.x on May 13',
there are enough positive votes create the 2.1.x branch on this Friday:
+1: justin, Brad, Sander, (me)
-1: wrowe
+1, but latter discussed problems: Jim
Instead of calling it branches/2.1.x, on IRC wrowe suggested going
straight
I propose the following policy apply to the 2.2.x branch, once (and if)
it is created:
Before GA: A 'soft' CTR. Any small bug fixes can be directly committed.
Any API changes must be reviewed by the list. (lazy consensus). Any
large changes must get voted on.
After first GA: Standard RTC, as
Hi,
I've been playing around with Apache2::Cookie and I've found that when
setting -path via
my $cookie = Apache2::Cookie-new($r, -path = $mypath...)
# I also set -name, -value, -expires, -domain, -secure the same way
ends up setting -path to 'domain' when I view the cookie, regardless of
the
At 08:29 PM 5/11/2005, Randy Kobes wrote:
That sounds great, but one consideration from the point of
view of Perl (eg, mod_perl) is that the dominant Win32 Perl
binary, from ActiveState, uses VC 6 to compile, and they
don't have any plans soon of changing that. But that might
change by the next
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2005-05-06 11:22:51 -0400 (Fri, 06 May 2005) $]
The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
Release history:
2.0.55 :
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2005-05-02 16:21:40 -0400 (Mon, 02 May 2005) $]
The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Release history:
[NOTE that only
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
httpd-test/perl-framework STATUS: -*-text-*-
Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $]
Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
framework failed)
* change existing tests that frob the
40 matches
Mail list logo
