hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kim young ill <khi...@googlemail.com>
Subject Re: FW: HTTP2 Expression of Interest: curl
Date Thu, 12 Jul 2012 23:11:56 GMT
+

On Thu, Jul 12, 2012 at 11:40 PM, Moore, Jonathan (CIM) <
Jonathan_Moore@comcast.com> 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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message