On Thu, Jun 11, 2015 at 4:33 PM, Stefan Eissing <[email protected]> wrote: > Two things: > > 1. the minimal thing to fix the situation is to return 421 instead of 400. H2 > clients will then open a new TLS connection for the request host. I don't > know if this breaks any HTTP/1 clients, however it should not.
I think this should be OK, HTTP/1 clients are prepared to received unknown error codes AFAICT. > > 2. Given that we answer not matching combinations with 421, the admin should > be given the opportunity to allow this via some directive. This makes it > easier for her to do "anti-sharding" for h2 clients. > > ap_matches_request_vhost() / ServerAlias is not the right choice, if I > understand it correctly, since the non-matching request is really intended > for another vhost and not just a using a fancy name for the real SNI one. > > If there were named SSL configurations, httpd could allow connection reuse > for all vhosts with the same SSL config. Alternatively, is there a good way > to check that two vhosts use the same certificate (key)? That could work as > well. That's why I (also) proposed to check the SNI against the current vhost's certificate's subject CN and/or AltNames (for wildcard certs). AIUI, the client should not reuse connections unless one of those matches. Why wouldn't that work? Regards, Yann.
