hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Speirs <wspe...@apache.org>
Subject Re: FW: HTTP2 Expression of Interest: curl
Date Fri, 13 Jul 2012 12:39:43 GMT
+1

Bill-

On Thu, Jul 12, 2012 at 7:11 PM, kim young ill <khiemu@googlemail.com>wrote:

> +
>
> 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