On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:
Also from RFC 7540, 9.2.1
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“
(Once the h2 session is established, renegotiation may appear before that.)
This is all a result of the „securing
Btw. I have the first report from a user that gets 400 answers in browsers when
mod_h2 is active because the browser reused the connection for another host.
Also from RFC 7540, 9.2.1
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“
(Once the h2 session is established,
Yann, I am with you and feel at least unease about this mixing.
But the RFC has been approved and browsers will adhere to it. So if we do not
enforce some policies in the server, connections will fail for mysterious
reasons. And tickets will be raised...
Am 09.06.2015 um 12:06 schrieb Yann
It just needed to get out :)
But I agree that since we are to implement the RFC, we must comply,
and find a way to still comply with HTTP/1.
Both checks on SNI and renegotiation occur in the post_read_request
hook, so we should be able to deal with vhost's parameters (configured
Protocols,
Prefork is the only (unix) MPM which is non-threaded.
On Jun 9, 2015, at 9:37 AM, Stefan Eissing stefan.eiss...@greenbytes.de
wrote:
Hi Knowledgeable List!
someone reported issues with mod_h2 in relation to some mod_proxy/mod_rewrite
setup of his. I added several test cases and all
I don't entirely understand the patch CHANGES, however...
On Tue, Jun 9, 2015 at 10:41 AM, wr...@apache.org wrote:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
* mod_ssl: bring SNI behavior into better conformance with RFC 6066
Graham and Jim, thanks for the advice.
As to prefork: as long as APR has threads and mutex and all these fine things,
I am pretty certain the mod_h2 itself does not have a problem with prefork.
The concern I have is: if people use prefork to have code running which is not
thread-safe, that
On 09 Jun 2015, at 3:37 PM, Stefan Eissing stefan.eiss...@greenbytes.de wrote:
My understanding is that one uses mpm_prefork when threads are to be avoided.
This is not what mod_h2 is about and so I consider disabling the module in a
prefork configuration. My thinking: if threads are not a
On Tue, Jun 9, 2015 at 5:46 PM, William A Rowe Jr wr...@rowe-clan.net wrote:
I don't entirely understand the patch CHANGES, however...
On Tue, Jun 9, 2015 at 10:41 AM, wr...@apache.org wrote:
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES
On Jun 9, 2015, at 3:42 AM, Yann Ylavic ylavic@gmail.com wrote:
It just needed to get out :)
But I agree that since we are to implement the RFC, we must comply,
and find a way to still comply with HTTP/1.
Both checks on SNI and renegotiation occur in the post_read_request
hook, so we
Committers,
we ended up short on reviewers in the security list, and are proceeding
shortly with 2.4.14.
I can't proceed with 2.2.30 until I get a third set of eyeballs on the
2.2.30-dev backport,
could someone offer to review ASAP? I will be tagging once the backport is
approved,
no other
My apologies for asking - but I am sure there are extra perl mods that need
to be installed before Apache-Test will operate as expected.
Unfortunately, it does not seem to demand them, and I have forgotten the
extra mods I loaded to get 100's of tests compared to the 13 I am getting
now.
I had
Hi Knowledgeable List!
someone reported issues with mod_h2 in relation to some mod_proxy/mod_rewrite
setup of his. I added several test cases and all seems fine. Then I found out
that he is running on a mpm_prefork configuration...
My understanding is that one uses mpm_prefork when threads are
On 6/8/15 10:17 AM, William A Rowe Jr wrote:
In this example, the patch was enhanced and the original reviewers' efforts
were thrown away. It's a shame to waste the limited review cycles.
Moving forwards, can we please do two things. 1) retain the original patch
and
vote in the STATUS,
14 matches
Mail list logo
