I’m pleased to announce the product of a few months of work: an HTTP/2 implementation written entirely in OCaml: h2.
h2 is based on the concepts in http/af, using Angstrom and Faraday for the parsing and serialization of the HTTP/2 framing layer, respectively. It also preserves the same API as http/af wherever possible, for familiarity reasons. The notable exception is the addition of a Reqd.push function that implements the HTTP/2 server push functionality.
h2 currently provides a server implementation, as well as runtime implementations for Lwt (UNIX) and Mirage (which I implemented at the last Mirage Hack Retreat in Marrakech).
The repo for h2 is here. The packages are not yet released to OPAM, a task I’m planning to complete in the next few days.
There were some licensing issues in this work related to oversights and ignorance on my part. I’m copying a text from a Reddit post of mine that tries to clarify the situation below.
Thanks everyone who brought all the licensing issues to my attention.
To clarify: I never intended to “steal” any code, I.e. passing work as mine without proper attribution to the original authors. The truth is that, while I’ve been doing open source for a little while, this is the first time that I’ve done any derivative work, and not being a lawyer, I really had no idea what exactly I needed to do (my thought process being that if my code didn’t bear any resemblance at all to the original code then I wouldn’t need to preserve the copyright headers).
It has been brought to my attention that I was wrong and I have therefore rectified the situation.
To clarify further what h2 is in comparison to http/af: h2 is an implementation of HTTP/2 (a totally different protocol) that tries to share the http/af types and API wherever possible. I understand now that this is derivative work because it shares the same underlying architecture, but I didn’t know that coming into it at first.
To all the affected parties: my apologies, I hope you can forgive me.
They are different protocols, so merging them isn’t appropriate. What’s a better way is to use the TLS ALPN extension to provide a multiplexing layer between http1/2, since this is what browsers use to distinguish between the different protocol versions while negotiating a secure connection at the moment. Then, we will need to design common abstractions between http/1/2/3 and dispatch to each of the individual protocol libraries depending on which one is chosen dynamically.