Hi,
We have configured Apache 2.2.6(64 bit) with openssl-0.9.8g on AIX5.2(64 bit).
Build openssl source after setting BUILD_MODE=64.
The issue is, when we start the Apache web server(./apachectl start), we are
getting segmentation fault in error_log.
This issue is coming only when openssl is
On Thu, 25 Oct 2007, Renu Tiwari wrote:
Hi,
We have configured Apache 2.2.6(64 bit) with openssl-0.9.8g on AIX5.2(64 bit).
Build openssl source after setting BUILD_MODE=64.
The issue is, when we start the Apache web server(./apachectl start), we are
getting segmentation fault in error_log.
No, when I tried doing make test, it failed.
Following is the error:-
Getting Private key
18378:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:m
d_rand.c:503:You need to read the OpenSSL FAQ, http://www.openssl.org/support/fa
q.html
18378:error:04088003:rsa
Sorry, but I do not get the purpose of this patch.
Why reading from our *client* (regardless if it is SSL or not)
when the backend is SSL?
Did you confuse c-input_filters and backend-connection-input_filters?
Regards
Rüdiger
-Ursprüngliche Nachricht-
Von: William A. Rowe, Jr.
-Ursprüngliche Nachricht-
Von: Nick Kew
Gesendet: Mittwoch, 24. Oktober 2007 03:07
An: dev@httpd.apache.org
Betreff: PR#41798 - mod_proxy URL mangling
Some time ago, I posted a draft fix for PR#41798:
http://www.mail-archive.com/dev@httpd.apache.org/msg37836.html
It
On Thu, 25 Oct 2007, Renu Tiwari wrote:
No, when I tried doing make test, it failed.
But when I tried to run make install and make, there I didn't
get any error.
make install doesn't do the test.
If your openssl doesn't pass make test, then it's broken. Fix that
first.
Also I have
On Thu, 25 Oct 2007 12:02:21 +0200
Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
I guess
use_uri = ap_construct_url(r-pool, r-uri, r);
Thanks - I thought I knew there was some such API function, but
didn't find it at the time.
However, on further reflection, I think it would be better
-Ursprüngliche Nachricht-
Von: Nick Kew
Gesendet: Donnerstag, 25. Oktober 2007 14:30
An: dev@httpd.apache.org
Betreff: Re: PR#41798 - mod_proxy URL mangling
On Thu, 25 Oct 2007 12:02:21 +0200
Plüm, Rüdiger, wrote:
However, on further reflection, I think it would be better
On Thu, 25 Oct 2007 16:00:40 +0200
Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
However, on further reflection, I think it would be better to
fall back to old behaviour in this case. The difficulty is that
this redirection catches cases where something is unnecessarily
but perfectly
On Oct 25, 2007, at 10:33 AM, Nick Kew wrote:
On Thu, 25 Oct 2007 16:00:40 +0200
Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
However, on further reflection, I think it would be better to
fall back to old behaviour in this case. The difficulty is that
this redirection catches cases
I think this is the problem: When a child is reaped normally after
exiting due to MaxSpareServers or MaxRequestsPerChild, it remains in
the scoreboard with status set to SERVER_DEAD, and it is removed from
the pid table.
Often that slot will be reused by a child created subsequently.
If it is
On 10/20/07, Chris Darroch [EMAIL PROTECTED] wrote:
Paritosh Shah wrote:
Thanks for the patches ... I'll take a look when I get some time.
I used resource-exists as the key instead of
NON_EXTANT_RESOURCE or NO_RESOURCE as suggested by Chris Darroch,
to avoid double negatives.
I
On Oct 25, 2007, at 11:00 AM, Jeff Trawick wrote:
I think this is the problem: When a child is reaped normally after
exiting due to MaxSpareServers or MaxRequestsPerChild, it remains in
the scoreboard with status set to SERVER_DEAD, and it is removed from
the pid table.
Often that slot will be
Paritosh Shah wrote:
There are really three states here ( wrt ap_meets_conditions())
1. resource exists
2. resource does not exist
3. nothing is known about existence of the resource
Currently ap_meets_conditions() does not make any assumptions about
existance of the resource ( case 3 ).
Plüm wrote:
Sorry, but I do not get the purpose of this patch.
Why reading from our *client* (regardless if it is SSL or not)
when the backend is SSL?
The original flaw, maybe long gone, is that mod_ssl implementation was
pull; on first read handshake would occur. The INIT blocking-flag was
On 10/25/2007 06:24 PM, William A. Rowe, Jr. wrote:
Plüm wrote:
Sorry, but I do not get the purpose of this patch.
Why reading from our *client* (regardless if it is SSL or not)
when the backend is SSL?
The original flaw, maybe long gone, is that mod_ssl implementation was
pull; on first
I had another look at ap_meets_conditions(), I guess what you say is
true. The current ap_meets_conditions() *does* assume resource exists
( although it does not explicitly state that ). And in that case
NO_RESOURCE would indeed be more appropriate.
- Paritosh.
On 10/25/07, Chris Darroch [EMAIL
17 matches
Mail list logo
