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, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. Which means for httpd that mod_ssl and mod_h2 need to talk to each other more. So, when a vhost allows all kinds of renegotiations / parameters, that should be fine and continue being useful when the connection talks HTTP/1. But when h2 is active, some sort of policy restriction needs to be applied (to make it fully standard compliant). Any ideas how to tackle this are appreciated. > Am 08.06.2015 um 15:56 schrieb Eric Covener <cove...@gmail.com>: > > What's the point of SNI if it can be used to select the correct vhost > before the handshake (modulo the port...), but TLS must possibly be > renegotiated later for subsequent requests? > > In configs that use separate certificates, it gets you the correct one, and > these are n/a to the coalescing problem > > In configs that use the same certificate, I guess it gets you slightly > different TLS parameters. If you use HTTP/2, you'll have to forego these and > per-dir renegotiations. > > Maybe the latter should just be deprecated, it seems like they cause constant > problems > > <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
