Hi, First of all, I will export Network.HPACK (and Network.HTTP2) only when the specs of HTTP/2.0 are fixed. Other modules are exported for debugging/discussion purpose only at this moment. I'm explaining, for instance, how to implement huffman encoding to other guys using this unnecessary exported documents.

A lot of the API uses the IO monad for no apparent reason. For example, the functions clearRefSets, removeRef, newEntry all seem to use IO unnecessarily, when they could be pure functions. That strikes me as bad style.

From peformance point of view, an mutable array is necessary to implement HPACK. Since this array is never shared and one-way update only, I first tried to implement HPACK purely with Array (and STArray) using unsafeFreeze and unsafeThaw. Unfortunately, this implementation is unstable (i.e. compiled code with -O causes infinite loop) and I gave up this approach. So, I decided to use IOArray.

Due to IOArray, some manipulation functions for Context is IO. I decided to make all manipulation functions having IO at this moment even if it is not necessary. This simplified the code of Network.HPACK.To and Network.HPACK.From. But I agree that Network.HPACK.Context should be cleaned up.

I'm also a bit dubious about HeaderSet being a type alias for [Header], since you're not hiding it but have a very long alias for (:) later in the same module.

You are right. I will fix this.

I don't like to see the print* functions scattered around in the public API, they look like debugging aids for your development purposes.

Please see above.

I don't understand why HeaderSet is a type alias but ReferenceSet is a new type (and should be using newtype instead of data). The ReferenceSet functions look likely to be inefficient.

http-types defines: type RequestHeaders = [Header] type ResponseHeaders = [Header] I would like to have the same type, but RequestHeaders and ResponseHeaders is not good because this is used both in HTTP request and HTTP response. I will use newtype for ReferenceSet. Thank you for pointing this out. --Kazu

Hi,

I may have missed something, but exactly what did you write in the earlier part of your email that addresses Bryan's concern about the print* statements?

Yes. I will consider Bryan's suggestion when I will modify the code drastically (maybe when the next draft will be published). But please understand that HTTP/2.0 is in the internet-draft stage. It is changing. Currently, the most important things are understanding what the new proposal is, considering how difficult to implement it, testing inter-operabilities, and feedback implementors' opinion to the protocol designers. After HTTP/2.0 is fixed and become an RFC, I can take time to clean up the code, stabilize API, and improve the performance. --Kazu

On Wed, Dec 18, 2013 at 02:59:58PM +0900, Kazu Yamamoto wrote:

...

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.

[snip]

Then, I will tackle TLS stuff. If necessary, I will write bindings to OpenSSL.

I admire your courage of writing an OpenSSL binding. I hope you know what sort of library the "enterprise grade" OpenSSL actually is. Last time I checked there was zero documentation, there seems to be a wiki now. In case you plan to read the source code, make sure you wear a helmet. We definitely do not want you to sustain head injuries while banging your head. Regards ppk

2013/12/18 Kazu Yamamoto

Hi,

...

I admire your courage of writing an OpenSSL binding. I hope you know what sort of library the "enterprise grade" OpenSSL actually is. Last time I checked there was zero documentation, there seems to be a wiki now. In case you plan to read the source code, make sure you wear a helmet. We definitely do not want you to sustain head injuries while banging your head.

I have read the source code of OpenSSL before so I know its quality. :-)

My first choice is to extend pure Haskell TLS. OpenSSL is a last resort. So, I said "if necessary".

I implemented NPN in Haskell TLS when I played around with SPDY/2, so at least that extension should be in place already :) https://hackage.haskell.org/package/tls-1.1.5/docs/Network-TLS.html#v:onSugg... https://hackage.haskell.org/package/tls-1.1.5/docs/Network-TLS.html#v:onNPNS... https://hackage.haskell.org/package/tls-1.1.5/docs/Network-TLS.html#v:getNeg... My SPDY/2 playground: https://github.com/kolmodin/spdy (a couple of different implementations, based both on conduit and io-streams) A lot has changed from SPDY/2 to http/2, so I'm not sure the spdy/2 code will be much help to you :/ Lennart

Thanks anyway.

--Kazu _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Hi web-devel, This is an old topic talked one year ago. I have sticked on this project since then and can report good news. I have implemented ALPN to hs-tls, which is already merged. Unfortunately, it was appeared that this is not good enough for HTTP/2. HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but hs-tls does not support neither ECDHE nor AES GCM. So, I have implemented both which should be merged eventually. A branch of Warp has integrated this hs-tls lib and http2 lib. This warp app can communicate with Firefox Nightly and Chrome 39 (with HTTP/2 enabled) by HTTP/2 over TLS now. --Kazu

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 _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Seconded! On Fri Nov 21 2014 at 4:22:31 AM Gregory Collins wrote:

Great work Kazu!!!

On Thu, Nov 20, 2014 at 6:08 PM, Kazu Yamamoto wrote:

...

Hi web-devel,

This is an old topic talked one year ago. I have sticked on this project since then and can report good news.

I have implemented ALPN to hs-tls, which is already merged. Unfortunately, it was appeared that this is not good enough for HTTP/2. HTTP/2 requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but hs-tls does not support neither ECDHE nor AES GCM. So, I have implemented both which should be merged eventually.

A branch of Warp has integrated this hs-tls lib and http2 lib. This warp app can communicate with Firefox Nightly and Chrome 39 (with HTTP/2 enabled) by HTTP/2 over TLS now.

--Kazu

...

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 _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

---

web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-- Gregory Collins _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel