Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1342426484.1998.2.camel@ubuntu>
Subject: Re: FW: HTTP2 Expression of Interest: curl
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Mon, 16 Jul 2012 10:14:44 +0200
In-Reply-To: 
 <9BD03E7AA1D81543AE3AD67CB6FADFEC5C6E3FA7@PACDCEXMB03.cable.comcast.com>
References: 
	<9BD03E7AA1D81543AE3AD67CB6FADFEC5C6E3FA7@PACDCEXMB03.cable.comcast.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0

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

+1

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
informed.

Oleg

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org