Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support SPDY v2/v3 protocol and NPN extension #680

wants to merge 21 commits into


None yet
2 participants

flier commented Feb 14, 2013

Chrome and Firefox has SPDY support for a while, which could improve the throughput and reduce the latency



bdarnell commented Feb 14, 2013

Cool, but also see #525, another SPDY implementation (which has tests and a client as well, so all else being equal I prefer that one).

My current feeling about SPDY is that it's too much of a moving target to merge at this time. The compression scheme used here is being abandoned in spdy/4 due to security problems (https://bugzilla.mozilla.org/show_bug.cgi?id=779413), so it doesn't really make sense to bring in a lot of zlib-related complexity right now.

I'd prefer to allow spdy implementations to develop separately from tornado itself for now. To that end I'd be happy to consider patches that make it possible to do so without relying on implementation details.

flier commented Feb 15, 2013

I agree there are a security problem which impact the SPDY client, but on the server side, I don't think it is very serious.

As you known, the attacker construct a SPDY request which fill a ZLIB compression window, he expect SPDY client or server use same compression context to compress the content, which generate a compressed stream with same size when guess is wrong, or difference size when the cookie is matching.

So, the key of attacker is that he can expect the compressed content size. But on the server side, we could easy break his expectation by add some random length HTTP header, such as a X-Salt header after :Host header. It will make the compressed response stream in difference size every time.

if self.stream.conn.salt_header:
headers.append((b'x-salt', base64.b64encode(os.urandom(random.randint(1, 8)))))

On the other hand, I think SPDY v3 with NPN will be more better than SPDY v2, I believe SPDY v4 will more mature, but we need not only waiting but also join, what's you opinion?

External work / Servers

Jetty Web Server: http://wiki.eclipse.org/Jetty/Feature/SPDY
Apache module for SPDY: http://code.google.com/p/mod-spdy/
Nginx Web Server: http://nginx.org/patches/spdy/README.txt
Python implementation of a SPDY server: http://github.com/mnot/nbhttp/tree/spdy
Ruby SPDY: https://github.com/igrigorik/spdy
node.js SPDY: https://github.com/indutny/node-spdy


bdarnell commented Feb 16, 2013

A random-length "salt" header increases the number of trials necessary to deduce the secret data, but it doesn't fundamentally prevent the attack.

As I said, I'm happy to facilitate work to support spdy on tornado as a third-party package, but I don't want to accept it into tornado proper until the protocol has stabilized.

@bdarnell bdarnell added the multiple label Jul 16, 2014


bdarnell commented Jul 5, 2015

NPN/ALPN is now supported. SPDY is obsoleted by the standardization of HTTP/2, for which see https://github.com/bdarnell/tornado_http2

@bdarnell bdarnell closed this Jul 5, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment