HTTP2 Expression of Interest: curl

Hi

This is a response to the call for expressions of interest:
http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

BACKGROUND

I am the project leader and maintainer of the curl project[1]. 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[2]. 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.

HTTP/2.0

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[3], 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.

HTTP AUTH

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.

[1] = http://curl.haxx.se/
[2] = http://daniel.haxx.se/blog/2012/05/16/300m-users/
[3] = http://spindly.haxx.se/

-- 

  / daniel.haxx.se

Received on Thursday, 12 July 2012 21:16:52 UTC