It’s amazing how fast time flies. I cannot believe it’s been almost two years already since I shifted gears and moved my focus away from the Cherokee project. Believe me when I say that, at the time, it was something tough to do for me.
This time also helped me to put things a little bit more in perspective, and to gain a better understanding on some of the upcoming technology I’m interested in, specially HTTP/2.0 and OpenStack.
Something worth noticing is the incredible hard time that the classic Web Server projects will have implementing HTTP/2.0. It applies to all of them: Apache, Nginx, Cherokee, etc. Why? Well, despite HTTPbis’ intention of not adding new functionality to HTTP/2.0 it certainly introduces so many fundamental changes to the protocol that it’d be extremely difficult to implement it properly on top of a “classic” HTTP/1 server. I know it well. I implemented SPDY in Cherokee, and then dropped the whole thing altogether when I realised the approach was just flawed.
How HTTP/2 support on top of HTTP/1 servers feel
Picture the HTTP/1 server as the “Nobel steed”. It’s indeed nobel and has served you well, but there is no way it will be able to handle its new rider. Do not bother trying to put it on an harness, it won’t work. They are two very different beats.
Despite the numerous implementation details, there are so many fundamental changes in how the protocol works that it would effectively require to rewrite the whole server from scratch to get it right. Although partial implementations can be achieved on top of the current HTTP/1 servers, they’d be quite limited, and therefore not what one could be looking for when moving Web resources over to HTTP/2.
I won’t go through the new layers of complexity that a HTTP/1 to HTTP/2 server re-implementation would require, but there are quite a few, specially if the target is to keep both protocols working seamlessly along each other. It sounds like an interesting topic for a future post though.
Bottom line, HTTP version 1.1 and the upcoming 2.0 version are like chalk and cheese, at least from a server logic point of view.
Even though it isn’t in the Top 5 most used Web Servers, Cherokee (HTTP/1.1) is currently running in hundred of thousands of devices (all the GoPro cameras, Digi embedded products, etc), plus on many critical and high demanding environments (European Space Agency, US Department of Energy, etc).
GoPro cameras run Cherokee
Quite a few mistakes were made in the Cherokee project, and I’m afraid I was the ultimate responsible of most of them. Unfortunately, not making it to the Netcraft's Top 5 most deployed Web Server list was the price we paid. I'd say the most common one was bad prioritisation, followed closely by an excessive focus on minor technical details and the misconception of having unlimited resources available (specially time). Truth be said, its license and the requirement of signing a contributor agreement in order to get code merged into the project did not help much either.
“Mistakes are always forgivable, if one has the courage to admit them.” — Bruce Lee
Good news, the lesson was well learned.
So, assuming all that.. What if the experience and know-how of having built Cherokee was put to the purpose of building new infrastructure for the upcoming HTTP protocol? A decade-long journey does certain teach you a lot of valuable things. A whole lotta ‘em.
I’ve certainly given that idea a lot of thought during the last couple of years. Somehow I supposed it would vanish after I dived deep into other FOSS projects, but I’m admit I’m still very attracted to the idea of putting this plan together. I can’t help myself.
All in all.. I’m doing it again. Oops!
I’m starting the development of a couple of new libraries to implement the complete upcoming HTTP/2.0 protocol.
I’m pushing the first few bits to my GitHub account, We’ll see how it evolves. Do not expect any fancy project website. All that eye candy will come later if the project sticks and starts attracting attention.
By now, you can find the first few bits at the libhpack repository, a C based, BSD licensed implementation of the HPACK spec (“Header Compression”) required in HTTP/2.0.
As it couldn’t be otherwise, I’d like to invite everybody to come by, give the project a try and contribute, either with code, ideas, thoughts or simply by spreading the word about it.