<div dir="ltr"><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">"</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"> 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.</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">"</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">It seems the brower can prevent the unreasonable behavior.</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">In reallity, It still exist some clients that dosen't perfom well in http2.</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">So it's kind of valuable to enable http2 by server.</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">It's not a good idea the put the patch in nginx,</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">Can you help to check the patch whether contains serious problem?</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">Maybe it's helpful for other guys. </pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">Thanks again.</pre></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 11:25 PM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thursday 08 June 2017 23:19:23 洪志道 wrote:<br>
> It sounds right.<br>
><br>
> According to the same situation, how does http2 protocol force other<br>
> virtual servers to process certificate (ssl handshake).<br>
><br>
> Example:<br>
><br>
> server {<br>
> listen 443 http2;<br>
> <a href="http://a.com" rel="noreferrer" target="_blank">a.com</a>;<br>
> ssl_certi....;<br>
> }<br>
><br>
> server {<br>
> listen 443 http2;<br>
> <a href="http://b.com" rel="noreferrer" target="_blank">b.com</a>;<br>
> ssl_certi....;<br>
> }<br>
><br>
> We assume sni is '<a href="http://a.com" rel="noreferrer" target="_blank">a.com</a>', then the connection contains different requests<br>
> with different domains.<br>
> That <a href="http://b.com" rel="noreferrer" target="_blank">b.com</a> will escape from ssl handshake. In fact, we need it to do the<br>
> ssl handshake.<br>
><br>
> Thanks.<br>
><br>
<br>
</span>It is called "Connection Reuse" in HTTP/2:<br>
<a href="https://tools.ietf.org/html/rfc7540#section-9.1.1" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>rfc7540#section-9.1.1</a><br>
<div class="HOEnZb"><div class="h5"><br>
wbr, Valentin V. Bartenev<br>
<br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a></div></div></blockquote></div><br></div>