" For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.
" It seems the brower can prevent the unreasonable behavior. In reallity, It still exist some clients that dosen't perfom well in http2. So it's kind of valuable to enable http2 by server. It's not a good idea the put the patch in nginx, Can you help to check the patch whether contains serious problem? Maybe it's helpful for other guys. Thanks again. On Thu, Jun 8, 2017 at 11:25 PM, Valentin V. Bartenev <[email protected]> wrote: > On Thursday 08 June 2017 23:19:23 洪志道 wrote: > > It sounds right. > > > > According to the same situation, how does http2 protocol force other > > virtual servers to process certificate (ssl handshake). > > > > Example: > > > > server { > > listen 443 http2; > > a.com; > > ssl_certi....; > > } > > > > server { > > listen 443 http2; > > b.com; > > ssl_certi....; > > } > > > > We assume sni is 'a.com', then the connection contains different > requests > > with different domains. > > That b.com will escape from ssl handshake. In fact, we need it to do the > > ssl handshake. > > > > Thanks. > > > > It is called "Connection Reuse" in HTTP/2: > https://tools.ietf.org/html/rfc7540#section-9.1.1 > > wbr, Valentin V. Bartenev > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel >
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
