Subject: HTTP2 Expression of Interest: curl

From: Daniel Stenberg <[email-masked]>
Date: Thu, 12 Jul 2012 23:16:23 +0200 (CEST)

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 11:40:30 +0100

Hi Daniel,

On 07/12/2012 10:16 PM, Daniel Stenberg wrote:
> authentication protocols. The HOBA, SCRAM and Mutual auth suggestions
> all seem perfectly doable and fine in my perspective.

Great.

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

This may be my ignorance but what'd be a "proper logout mechanism"?
Maybe someone's documented requirements or a wish-list somewhere?

I put in a bit on this in the hoba draft, (but to be honest, without
really understanding much about it:-), so I'd love to know a bit more
about what's needed, e.g. how ought it affect cookies, TLS session
resume, etc. etc.

Ta,
S.

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 14 Jul 2012 00:01:35 +0900

Dear Daniel,

2012/7/13 Daniel Stenberg <[email-masked]>:
> authentication protocols. The HOBA, SCRAM and Mutual auth suggestions all
> seem perfectly doable and fine in my perspective.

Great, too.

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

I agree that lack of logon control features is one of critical issues
for deploying http authentication to World Wide Web systems.
In my set of proposals, the problem is addressed in the
separate draft called draft-oiwa-httpbis-auth-extension-00.
It may be not directly related to your project, but if you have any
feedback or a comment about the protocol design of that draft,
it will be greatly appreciated.

Regards,

Yutaka

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]