+ On Thu, Jul 12, 2012 at 11:40 PM, Moore, Jonathan (CIM) < [email protected]> wrote:
> Do we, as a community, want to express some interest in HTTP/2.0 on behalf > of HttpComponents? > > Jon > ........ > Jon Moore > Comcast Cable > > > > > > > > On 7/12/12 5:16 PM, "Daniel Stenberg" <[email protected]> wrote: > > >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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
