On Thursday 23 January 2014 15:54:58 Alex wrote:
> > On Thu, Jan 23, 2014 at 11:17:42AM +0000, Pankaj Mehta wrote:
>
> Hi,
>
> > These blocks have different ssl certificates. I understand that if I enable
> > SNI in nginx and the client supports it, then we have a predictable
> > behaviour where nginx will use the correct ssl parameters from the server
> > block corresponding to that hostname. But I have no idea which ssl config
>
> One thing I became painfully aware of last time is that when you use
> SSL-enabled server blocks with SNI, a listen directive from one block
> may overwrite the listen directive from another one.
>
> For example, when I have:
>
> server {
> listen 443 ssl;
> server_name www.host1.com;
>
> ...
> }
>
> and
>
> server {
> listen 443 ssl spdy;
> server_name www.host2.com;
>
> ...
> }
>
> Even though the listen directive for server block of www.host1.com does
> not define SPDY, it accepts SPDY connections as well. In other words, if
> you want to disable SPDY, you'd have to make sure that it doesn't appear
> in any server block listen directive (assuming you're using SNI rather
> than dedicated IPs).
>
> I am not sure if this behavior can be avoided. nginx advertises spdy/2
> via the NPN TLS extension. During the TLS handshake, would it be
> possible to first parse the hostname the client is attempting to connect
> (SNI), and only then decide whether to advertise SPDY via NPN or not
> depending on the hostname's listen directive?
>
Sorry for the late answer.
This behavior cannot be avoided since even if you do not advertise SPDY via
NPN/ALPN for some virtual hosts, but do for another, then browsers still be
able to request any of them using an already established SPDY connection.
wbr, Valentin V. Bartenev
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
