On 18.11.2011 06:32, Kaspar Brand wrote:
As I can't think of any good reason why a new major version of an HTTPS
server released in late 2011 should still support insecure SSL protocol
cruft from the 1990s (v2 was superseded about 15 years ago, when SSLv3
was introduced), I went for the first
Hi all,
Right now, we only keep track of the real IP address of the incoming
connection within conn_rec, and with a simple webserver that's fine.
In a world containing load balancers, we now have the real IP address
(the load balancer) and the effective IP address (the IP that
connected
On Fri, Nov 18, 2011 at 8:24 AM, Graham Leggett minf...@sharp.fm wrote:
Hi all,
Right now, we only keep track of the real IP address of the incoming
connection within conn_rec, and with a simple webserver that's fine.
In a world containing load balancers, we now have the real IP address (the
On 18 Nov 2011, at 4:05 PM, Jeff Trawick wrote:
A. modules keep using conn_rec, core keeps track of TCP peer for
logging, post-read-request or some other per-request hook used to set
effective client in conn_rec
ugly updates to conn_rec by some module; client is really per-request
in some
On 18.11.2011 13:09, Rainer Jung wrote:
You might want to drop the -SSLv2 from our SSLCipherSuite in
docs/conf/extra/httpd-ssl.conf.in then as well.
You're right, yes. As there were no objections to the changes I proposed
on the list a few days ago, I now committed them with r1203752/r1203753.
On 18.11.2011 18:20, Kaspar Brand wrote:
On 18.11.2011 13:09, Rainer Jung wrote:
You might want to drop the -SSLv2 from our SSLCipherSuite in
docs/conf/extra/httpd-ssl.conf.in then as well.
You're right, yes. As there were no objections to the changes I proposed
on the list a few days ago, I
On 18 Nov 2011, at 4:23 PM, Graham Leggett wrote:
The lines I was thinking along was that effective_ip was in addition
to the remote_ip, rather than instead of. The log format wouldn't
change, there would be a new value that would represent the
effective IP, in addition to the existing
On Tue, Nov 15, 2011 at 10:51 AM, pque...@apache.org wrote:
Log:
Create a new lock free circular queue, and use it in the EventMPM to
remove the timeout mutex that was wrapping both timeout queue operations
and pollset operations.
@@ -1632,6 +1672,20 @@ static void * APR_THREAD_FUNC
Hi together,
I'm messing around with a strange bug now for a few days:
When enabling mod_cache in my reverse-proxy scenario, the first file
with a filesize above some threshold gets delivered corrupted,
subsequent requests served from cache are fine.
I noticed it first with some broken images
On Fri, Nov 18, 2011 at 2:43 PM, Greg Ames ames.g...@gmail.com wrote:
On Tue, Nov 15, 2011 at 10:51 AM, pque...@apache.org wrote:
Log:
Create a new lock free circular queue, and use it in the EventMPM to
remove the timeout mutex that was wrapping both timeout queue operations and
pollset
On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick traw...@gmail.com wrote:
Try this:
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c(revision 1203816)
+++ server/mpm/event/event.c(working copy)
@@ -1483,9
Hi,
in case any of you also have lots of test failures with libwww-perl 6.0.3,
setting these env vars fixes most of them for me:
PERL_NET_HTTPS_SSL_SOCKET_CLASS=Net::SSL
PERL_LWP_SSL_VERIFY_HOSTNAME=0
No idea why Net::SSL works but IO::Socket::SSL doesn't. The remaining
failures
On Fri, Nov 18, 2011 at 4:06 PM, Greg Ames ames.g...@gmail.com wrote:
On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick traw...@gmail.com wrote:
Try this:
Index: server/mpm/event/event.c
===
--- server/mpm/event/event.c
On Fri, Nov 18, 2011 at 4:38 PM, Jeff Trawick traw...@gmail.com wrote:
but my fears about the performance of the design seem to be confirmed.
my
fastest run so far with trunk + this patch,
Requests per second:7749.66 [#/sec] (mean)
backing up to the prior state (with the mutex),
After several prods, it seems the security@ and hackathon participants
can't be drawn out of their shells on to dev@. So I'll simply call for
a majority vote on the following statement...
Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth;
[ ] Represents a security
On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote:
After several prods, it seems the security@ and hackathon participants
can't be drawn out of their shells on to dev@. So I'll simply call
for
a majority vote on the following statement...
Resource abuse of an .htaccess config in the
On Sat, 2011-11-19 at 01:46 +0200, Graham Leggett wrote:
On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote:
After several prods, it seems the security@ and hackathon participants
can't be drawn out of their shells on to dev@. So I'll simply call
for
a majority vote on the
On 18 Nov 2011, at 9:50 PM, f_los_ch wrote:
When enabling mod_cache in my reverse-proxy scenario, the first file
with a filesize above some threshold gets delivered corrupted,
subsequent requests served from cache are fine.
Can you confirm if the following patch makes any difference for you?
On 11/11/2011 10:49 AM, William A. Rowe Jr. wrote:
On approval of this plan, I would offer to introduce the EOL notices
(as we ultimately committed to 1.3), tag and roll 2.0.65 on Nov 26th
and we would potentially approve and release 2.0 'final' this month.
I have responded to all negative
On Friday 18 November 2011, William A. Rowe Jr. wrote:
Resource abuse of an .htaccess config in the form of
cpu/memory/bandwidth;
[ ] Represents a security defect
[X] Is not a security defect
This would obviously need to be clarified in the associated
.htaccess documentation, be
On Friday 18 November 2011, Graham Leggett wrote:
besides the ugliness of updating conn_rec, are there known
functional drawbacks of the existing mechanism, assuming that
the module which sets the client also sets a note to allow
logging of the TCP peer if desired?
There is also the
Nevermind that you failed to be consistent in tag values between
logging schemas... nothing in this proposal addresses the reason
that I myself had implemented mod_remoteip, which was authn/authz
control. In the limited scenario you have considered, authn is
pretty much a noop on the physical
On Friday 18 November 2011, Kaspar Brand wrote:
all simply stands for +SSLv3 +TLSv1,
so we might just leave the default config as is - i.e., not have
any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf.
We may have TLSv1.1 and TLSv1.2 in the future. Changing the
default config to an
On Fri, Nov 18, 2011 at 10:05 PM, Stefan Fritsch s...@sfritsch.de wrote:
On Friday 18 November 2011, Kaspar Brand wrote:
all simply stands for +SSLv3 +TLSv1,
so we might just leave the default config as is - i.e., not have
any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf.
We may
On 18.11.2011 18:47, Rainer Jung wrote:
Fine with me. Current SSLCipherSuite for 2.2 definitely needs
improvement and latest 2.4 should be the way to go.
Except: Since SSLv2 is still available for 2.2, the -SSLv2 is needed in
the cipher list.
Please feel free to go ahead an remove my
25 matches
Mail list logo
