hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moore, Jonathan (CIM)" <Jonathan_Mo...@Comcast.com>
Subject FW: HTTP2 Expression of Interest: curl
Date Thu, 12 Jul 2012 21:40:16 GMT
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" <daniel@haxx.se> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message