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
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html