Chrome and Firefox has SPDY support for a while, which could improve the throughput and reduce the latency
ignore the IDEA project
handle SPDY connection in HTTPServer.handle_stream method
support SYN_STREAM frame
support to parse SYN_STREAM frame
decompress and decode the header block before parse it
use ctypes to load zlib as backup of zlib_stream library
move the SPDY related functions to the SPDYServer class
parse SYN_STREAM frame
parse SPDY request
SPDYRequest inherit from HTTPRequest for SPDY stream
support to send SYN_REPLY frame
send frame by events
handle HEADERS, GOAWAY, NOOP and PING frames
parse and send SETTINGS frame
parse and send WINDOW_UPDATE frame
parse CREDENTIAL frame
run tornado as SSL server
port to Python 3.x
parse RstStream frame
dump frames when send/recv it
use NPN to select protocol on Python 3.3 or later
make chrome happy
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.
add x-salt header to avoid two tries attack
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.
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
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.
NPN/ALPN is now supported. SPDY is obsoleted by the standardization of HTTP/2, for which see https://github.com/bdarnell/tornado_http2