On 29.09.2015 18:24, Reindl Harald wrote:
> i just restarted the servers and disabled stapling since all our
> servcies where unreachable (before i write the second mail 5 different
> hosts with several sites where affected)
>
> in fact the error caching does more harm than benefits - IHMO a bet
Am 29.09.2015 um 17:31 schrieb Jeff Trawick:
On 09/29/2015 04:20 AM, Reindl Harald wrote:
is that by intention?
The default timeout before retrying an error seems to be 10 minutes (see
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingerrorcachetimeout),
which is pretty excessive.
On 09/29/2015 04:20 AM, Reindl Harald wrote:
is that by intention?
The default timeout before retrying an error seems to be 10 minutes (see
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingerrorcachetimeout),
which is pretty excessive.
As far as you recall about the time period
Am 29.09.2015 um 10:20 schrieb Reindl Harald:
is that by intention?
firefox refused to open our adminpanel with the error below until i
restarted httpd - i suggest the server should retry SSLUseStapling when
a new client connects and it has failed for whatever reason
SSLUseStapling On
An err
On 29 Sep 2015, at 11:40 AM, Daniil Iaitskov wrote:
> I am patching HTTP proxy module to pass trailing headers from a client to an
> origin server.
>
> I want it to be compatible with RFCs, and I was stumbled with 2 statements
> from
> them.
>
> 1. Trailer header is hop-by-hop so it cannot b
Hi Christophe,
On Tue, Sep 29, 2015 at 1:00 PM, Christophe JAILLET
wrote:
>
> I think that r1705257 should also be backported to 2.4.x
Done in r1705839.
>
> There are also some differences related to h2/http2 in:
>Apache-apr2.dsw
>Apache.dsw
> But for these ones, 2.4.x seems to be more
Hi,
I think that r1705257 should also be backported to 2.4.x
There are also some differences related to h2/http2 in:
Apache-apr2.dsw
Apache.dsw
But for these ones, 2.4.x seems to be more up to date.
There is also some references to httpd-h2.conf, httpd-h2.conf.in which
may be better nam
On Tue, Sep 29, 2015 at 10:38 AM, Joe Orton wrote:
> On Fri, Sep 25, 2015 at 03:54:56PM +0200, Yann Ylavic wrote:
>> Couldn't we completely remove the flush from bio_filter_in_read() then?
>> Or make it conditional to OpenSSL < 0.9.8m (since we support 0.9.8a at
>> least)?
>
> That looks correct
Hi List,
I am patching HTTP proxy module to pass trailing headers from a client to
an origin server.
I want it to be compatible with RFCs, and I was stumbled with 2 statements
from
them.
1. Trailer header is hop-by-hop so it cannot be transferred to outgoing
connection
(RFC2616 13.5.1 - it's
On Fri, Sep 25, 2015 at 03:54:56PM +0200, Yann Ylavic wrote:
> Couldn't we completely remove the flush from bio_filter_in_read() then?
> Or make it conditional to OpenSSL < 0.9.8m (since we support 0.9.8a at least)?
That looks correct to me, +1.
Regards, Joe
is that by intention?
firefox refused to open our adminpanel with the error below until i
restarted httpd - i suggest the server should retry SSLUseStapling when
a new client connects and it has failed for whatever reason
SSLUseStapling On
An error occurred during a connection to ***:844
On 07/24/2015 02:09 PM, ic...@apache.org wrote:
> Author: icing
> Date: Fri Jul 24 12:09:44 2015
> New Revision: 1692486
>
> URL: http://svn.apache.org/r1692486
> Log:
> new Protocols directive and core API changes to enable protocol switching on
> HTTP Upgrade or ALPN, implemented in mod_ssl a
12 matches
Mail list logo
