On Tuesday 15 January 2013 05:55:43 digitalpoint wrote:
> Well... the underlying errors went away, but it seems the new SPDY patch
> broke being able to handle multiple hosts on the same SPDY connection now
> (it worked under 1.3.10 just fine).
>
> For example, we have a SSL cert for both digitalpoint.com and dpstatic.com
> (dpstatic.com is a cookieless domain for serving static content), so SPDY
> attempts to use the same connection for multiple hosts. See SPDY session
> list here:
> http://f.cl.ly/items/0T1u3g0h0e1A0D1g2N0s/Image%202013.01.08%2011:59:48%20A
> M.png
>
> With the SPDY patch for 1.3.11, now requests to *.dpstatic.com are
> *actually* being sent to digitalpoint.com (and getting a file not found).
> So somehow during a SPDY connection, the host for an individual request is
> being ignored somewhere along the way.
>
> Top browser is Chrome (SPDY connection), bottom browser is Safari (no SPDY
> support)... the end result is a SPDY connection will yield different
> results vs the "traditional" SSL connection:
> http://f.cl.ly/items/3K1Q2N1I3B000c0b0614/Image%202013.01.14%205:52:31%20PM
> .png
>
> Again, this worked as expected (ability for SPDY to properly share a
> connection across multiple hosts) with 1.3.10.
>

There is no difference between 1.3.10 and 1.3.11 in terms of SPDY.
In fact, 1.3.10 has serious bugs (see: http://nginx.org/en/CHANGES),
and you should use 1.3.11 instead.

The big difference is between spdy54 and spdy55+ patches. A large part of
SPDY implementation was rewritten in spdy55, and also some relevant parts
of nginx got new code.

One of those changes makes nginx more RFC 6066 compliant. Here is some quotes:

3. Server Name Indication

[...]

If an application negotiates a server name using an application
protocol and then upgrades to TLS, and if a server_name extension is
sent, then the extension SHOULD contain the same name that was
negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.

11.1. Security Considerations for server_name

[...]

Since it is possible for a client to present a different server_name
in the application protocol, application server implementations that
rely upon these names being the same MUST check to make sure the
client did not present a different name in the application protocol.

from http://tools.ietf.org/html/rfc6066

And you will not find in SPDY draft.2 specification any information about
the "ability for SPDY to properly share a connection across multiple hosts":
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2

Apparently by making TLS SNI in nginx more RFC-compliant I unintentionally
broke SPDY.

Well, it's safe to use spdy54 with 1.3.11:
http://nginx.org/patches/spdy/patch.spdy-54.txt
and I recommend you to use it while I will think about a solution.

Thanks again for testing. I hope to fix the issue soon.

wbr, Valentin V. Bartenev

--
http://nginx.com/support.html
http://nginx.org/en/donation.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx