On Thu, 2012-07-12 at 21:40 +0000, Moore, Jonathan (CIM) wrote:
> Do we, as a community, want to express some interest in HTTP/2.0 on behalf
> of HttpComponents?
I think we certainly should. I do not know how much we could really
contribute to the effort but It would definitely be worthwhile to stay
> Jon Moore
> Comcast Cable
> On 7/12/12 5:16 PM, "Daniel Stenberg" <daniel@...> wrote:
> >This is a response to the call for expressions of interest:
> >http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI > >
> >I am the project leader and maintainer of the curl project. We are the
> >source project that makes libcurl, the transfer library and curl the
> >line tool. It is among many things a client-side implementation of HTTP
> >HTTPS (and some dozen other application layer protocols). libcurl is very
> >portable and there exist around 40 different bindings to libcurl for
> >all languages/enviornments imaginable. We estimate we might have upwards
> >million users or so. 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
> >that can be improved.
> >We've implemented HTTP/1.1 and we intend to continue to implement any and
> >widely deployed transport layer protocols for data transfers that appear
> >the Internet. This includes HTTP/2.0 and similar related protocols.
> >curl has not yet implemented SPDY support, but fully intends to do so.
> >current plan is to provide SPDY support with the help of spindly, a
> >separate SPDY library project that I lead.
> >We've selected to support SPDY due to the momentum it has and the
> >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
> >connections problems in a decent way that appears to work in reality too.
> >believe SPDY keeps enough HTTP paradigms to be easily upgraded to for
> >parties, and yet the ones who can't or won't can remain with HTTP/1.1
> >too much pain. Also, while Spindly is not production-ready, it has still
> >me the sense that implementing a SPDY protocol engine is not rocket
> >and that the existing protocol specs are good.
> >By relying on external libs for protocol and implementation details, my
> >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
> >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
> >"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
> >the ietf-http-wg mailing list on HTTP details for as long as I have time
> >HTTP AUTH
> >curl currently supports Basic, Digest, NTLM and Negotiate for both host
> >Similar to the HTTP protocol, we intend to support any widely adopted
> >authentication protocols. The HOBA, SCRAM and Mutual auth suggestions all
> >perfectly doable and fine in my perspective.
> >However, if there's no proper logout mechanism provided for HTTP auth I
> >forsee any particular desire from browser vendor or web site creators to
> >any of these just like they don't use the older ones either to any
> >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
> >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
> >far as possible and similar to how RFC2617 is separate from RFC2616 it
> >be this time around too. The auth mechnism should not be too tightly knit
> >the HTTP protocol.
> >The day we can clense connection-oriented authentications like NTLM from
> >HTTP world will be a happy day, as it's state awareness is a pain to deal
> >in a generic HTTP library and code.
> > = http://curl.haxx.se/ > > = http://daniel.haxx.se/blog/2012/05/16/300m-users/ > > = http://spindly.haxx.se/ > >
> > / daniel.haxx.se
> To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... >
To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@...