+1 Bill-
On Thu, Jul 12, 2012 at 7:11 PM, kim young ill <[email protected]>wrote: > + > > 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] > > > > >
