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]
