For the readers of my blog, this is a copy of what I posted to the httpbis mailing list on July 12th 2012.
This is a response to the httpis call for expressions of interest
I am the project leader and maintainer of the curl project. We are the openÂ source project that makes libcurl, the transfer library and curl the commandÂ line tool. It is among many things a client-side implementation of HTTP andÂ HTTPS (and some dozen other application layer protocols). libcurl is veryÂ portable and there exist around 40 different bindings to libcurl for virtuallyÂ all languages/enviornments imaginable. We estimate we might have upwards 500
million users or so. We’re entirely voluntary driven without any paidÂ developers or particular company backing.
HTTP/1.1 problems I’d like to see adressed
Pipelining – I can see how something that better deals with increasingÂ bandwidths with stagnated RTT can improve the end users’ experience. It is notÂ easy to implement in a nice manner and provide in a library like ours.
Many connections – to avoid problems with pipelining and queueing on theÂ connections, many connections are used and and it seems like a general wasteÂ that can be improved.
We’ve implemented HTTP/1.1 and we intend to continue to implement any and allÂ widely deployed transport layer protocols for data transfers that appear onÂ the Internet. This includes HTTP/2.0 and similar related protocols.
curl has not yet implemented SPDY support, but fully intends to do so. TheÂ current plan is to provide SPDY support with the help of spindly, aÂ separate SPDY library project that I lead.
We’ve selected to support SPDY due to the momentum it has and the multipleÂ existing implementaions that A) have multi-company backing and B) prove it toÂ be a truly working concept. SPDY seems to address HTTP’s pipelining and many-connections problems in a decent way that appears to work in reality too. IÂ believe SPDY keeps enough HTTP paradigms to be easily upgraded to for mostÂ parties, and yet the ones who can’t or won’t can remain with HTTP/1.1 withoutÂ too much pain. Also, while Spindly is not production-ready, it has still givenÂ me the sense that implementing a SPDY protocol engine is not rocket scienceÂ and that the existing protocol specs are good.
By relying on external libs for protocol and implementation details, my hopesÂ is that we should be able to add support for other potentially comingÂ HTTP/2.0-ish protocols that gets deployed and used in the wild. In the curlÂ project we’re unfortunately rarely able to be very pro-active due to theÂ nature of our contributors, which tends to make us follow the rest andÂ implement and go with what others have already decided to go with.
I’m not aware of any competitors to SPDY that is deployed or used to anyÂ particular and notable extent on the public internet so therefore no otherÂ “HTTP/2.0 protocol” has been considered by us. The two biggest protocolÂ details people will keep mention that speak against SPDY is SSL and theÂ compression requirements, yet I like both of them.Â I intend to continue to participate in dicussions and technical arguments onÂ the ietf-http-wg mailing list on HTTP details for as long as I have time andÂ energy.
curl currently supports Basic, Digest, NTLM and Negotiate for both host andÂ proxy.
Similar to the HTTP protocol, we intend to support any widely adoptedÂ authentication protocols. The HOBA, SCRAM and Mutual auth suggestions all seemÂ perfectly doable and fine in my perspective.
However, if there’s no proper logout mechanism provided for HTTP auth I don’tÂ forsee any particular desire from browser vendor or web site creators to useÂ any of these just like they don’t use the older ones either to any significantÂ extent. And for automatic (non-browser) uses only, I’m not sure there’sÂ motivation enough to add new auth protocols to HTTP as at least historicallyÂ we seem to rarely be able to pull anything through that isn’t pushed for by atÂ least one of the major browsers.
The “updated HTTP auth” work should be kept outside of the HTTP/2.0 work asÂ far as possible and similar to how RFC2617 is separate from RFC2616 it shouldÂ be this time around too. The auth mechnism should not be too tightly knit toÂ the HTTP protocol.
The day we can clense connection-oriented authentications like NTLM from theÂ HTTP world will be a happy day, as it’s state awareness is a pain to deal withÂ in a generic HTTP library and code.