Hi Greg,
This is a nice start. I considered implementing SPDY myself soon after the spec was first published but the TLS stuff seemed too daunting. At the time I think Chrome was using a bunch of in-tree OpenSSL patches to support next-protocol-negotiation / TLS snap start / etc. It looks like the HTTP 2 draft has gotten rid of those requirements but the TLS server name indication extension must be supported. HsOpenSSL doesn't have bindings for the needed functions (SSL_CTX_set_tlsext_servername_callback() / SSL_get_servername()) and the tls library (which I am personally reluctant to use for "crypto is hard to do right and you really want to use widely-audited code" reasons) doesn't seem to have an implementation yet either. OpenSSL support seems to be the easier nut to crack there.
Indeed, TLS is tough. All existing implementations of HTTP/2.0 are using OpenSSL HEAD, not released one. Also, spec is changing, i.e. NPN (SPDY's one, proposals from the server side) vs ALPN (current HTTP/2.0's one, proposals from the client side). I finished inter-operability test of HPACK with one in nodejs and one in C. The next step is to implement HTTP/2.0 framing and plain-text communication. Then, I will tackle TLS stuff. If necessary, I will write bindings to OpenSSL. --Kazu