W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re[2]: SPDY = HTTP/2.0 or not ?

From: Adrien W. de Croy <adrien@qbik.com>
Date: Mon, 26 Mar 2012 00:55:31 +0000
To: "Brian Pane" <brianp@brianp.net>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em6c3cc85d-91b2-440e-9073-55b913bdbe8d@BOMBED>
wrt proxies and TLS... 
making TLS hop by hop rather than end to end would make life a lot 
easier, and still provide protection for coffee shop users, proxy 
access to payload, while not mandating the CPU burden in trusted 
environments (e.g. reverse proxy).

------ Original Message ------
From: "Brian Pane" <brianp@brianp.net>
To: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 26/03/2012 1:50:39 p.m.
Subject: Re: SPDY = HTTP/2.0 or not ?
>On Sun, Mar 25, 2012 at 3:59 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>>       2. SPDY's requirement for SSL is never going to fly with
>>          p0rn^Wmultimedia sites, national emergency services,
>>          and other high volume/high spike sites.
>It looks like the current SPDY proposal only requires TCP, not SSL:
>Nonetheless, I think it would be reasonable for HTTP/2.0 to require SSL.
>When HTTP/0.9 was first deployed, the typical client environment was
>an academic LAN where the users trusted each other.  Today, the
>typical client environment is a coffee shop with an open wireless
>If HTTP/2.0 has an operational life as long as HTTP/1.x has had,
>decisions made this year will determine the default security of the
>web in 2028.
>If the HTTP/2.0 standard mandates TLS, it will create pressure for
>implementors in the short term.  But that's good, because implementors
>will see it as an opportunity.  Hardware developers will step up their
>efforts to accelerate common ciphersuites.  Software developers will
>step up their efforts to make session resumption scale.  And the
>per-byte and per-session cost will drop.  And all those people in the
>coffee shop will be better protected.
Received on Monday, 26 March 2012 00:56:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC