I've spent some time reviewing the current state of mod_ftp trunk, and believe
we are essentially inter-operable with httpd 2.4 at last. SNI poses some
problems, but they are beyond the scope of a 'quck fix' - in an FTP
conversation we might be looking at an SNI identifier on the command
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
all means a shortcut for ``+SSLv3 +TLSv1'' or - when using OpenSSL
1.0.1 and later - ``+SSLv3 +TLSv1 +TLSv1.1
Am 17.10.2014 um 12:02 schrieb Takashi Sato:
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
all means a shortcut for ``+SSLv3 +TLSv1'' or - when using
The pcap does not show the window scaling factor (SYN SYN/ACK not captured).
Without this factor, the client's receive window is of 65, which would
need a scaling factor of at least 9 (which is not the default AFAICT
in linux) to fit the 29216 bytes (ie. 53359 - 24143) in flight at the
time of the
On Fri, Oct 17, 2014 at 7:31 AM, Yann Ylavic ylavic@gmail.com wrote:
The pcap does not show the window scaling factor (SYN SYN/ACK not
captured).
Without this factor, the client's receive window is of 65, which would
need a scaling factor of at least 9 (which is not the default AFAICT
in
On Fri, Oct 17, 2014 at 1:52 PM, Eric Covener cove...@gmail.com wrote:
One interesting part that might not have came through -- my file was
originally 130k, then 120k, and now only about 30k. It's always only the
one lastpartial frame that is delayed by 1 RTT.
The only one wih the P[U]SH
I think I fouled up my server (TCP_NODELAY unset) while tinkering with the
congestion issue I started with. Thanks and sorry to waste your time Yann.
On Fri, Oct 17, 2014 at 8:26 AM, Yann Ylavic ylavic@gmail.com wrote:
On Fri, Oct 17, 2014 at 1:52 PM, Eric Covener cove...@gmail.com wrote:
OK, no problem.
On Fri, Oct 17, 2014 at 3:05 PM, Eric Covener cove...@gmail.com wrote:
I think I fouled up my server (TCP_NODELAY unset) while tinkering with the
congestion issue I started with. Thanks and sorry to waste your time Yann.
On Fri, Oct 17, 2014 at 8:26 AM, Yann Ylavic
On Fri, Oct 17, 2014 at 9:05 AM, Eric Covener cove...@gmail.com wrote:
I think I fouled up my server (TCP_NODELAY unset) while tinkering with the
congestion issue I started with. Thanks and sorry to waste your time Yann.
Actually that's not really true after getting a clean build. But it
that's right, SSLv3 is no longer secure.
2014-10-17 19:14 GMT+09:00 Reindl Harald h.rei...@thelounge.net:
Am 17.10.2014 um 12:02 schrieb Takashi Sato:
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
On 17.10.2014 12:02, Takashi Sato wrote:
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
all means a shortcut for ``+SSLv3 +TLSv1'' or - when using
On Friday 17 of October 2014, Kaspar Brand wrote:
On 17.10.2014 12:02, Takashi Sato wrote:
SSLv3 is now insecure (CVE-2014-3566, POODLE)
Let's disable SSLv3 by default, at least trunk.
SSLProtocol default is all.
http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
all
Actually, I think Sorin's code makes more sense than he gives himself credit
for. It looks like it basically tries to re-execute the filter chain from
scratch, after removing the failed filter and inserting the error filter.
It doesn't really swap the output and error headers-- it just clears
Resending since it doesn't seem to have been delivered.
On Thu, Oct 16, 2014 at 11:26 AM, Pon Umapathy Kailash S
pon.umapa...@gmail.com wrote:
Hi,
I am facing the an issue where a SSL packet from IE10 doesn't reach
the client processing thread for a particular connection(more details
below).
Your first message was delivered less than 24 hours ago - most of us are
not paid by the Apache modules developers list, meaning we are stricly
volunteer, and 24 hours might not be enough time. I would suggest
patience, especially while asking questions on the fringes of this lists
expertise.
15 matches
Mail list logo
