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

SPDY = HTTP/2.0 or not ?

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 25 Mar 2012 10:59:27 +0000
To: Julian Reschke <julian.reschke@gmx.de>
cc: (wrong string) ™ˆ™˜Œ)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <31698.1332673167@critter.freebsd.dk>
In message <4F6E5D90.9050904@gmx.de>, Julian Reschke writes:

>> Since it's possible to layer different (future) versions of HTTP on top
>> of SPDY, don't we need the ":version" header to preserve all
>> information? And similarly, we can conceivably handle different schemes
>> over SPDY, such as https (the obvious one), http, ws, wss, etc, so I
>> think including ":scheme" is important.
>If we see SPDY as a transport layer only yes; if we consider it 
>HTTP/2.0; maybe not.

Ok, can we just settle this once and for all ?


	1. HTTP/1.1 already has two different widely used transport
	   protocols: HTTP and HTTPS

	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.

	3. There is significant interest in HTTP over UDP in certain

	4. There are already a number of HTTP over FOO definitions,
	   for various values of FOO.

	5. Any realistic HTTP/2.0 implementation will be multiprotocol
	   anyway, because it will also have to support HTTP/1.1
	   and probably HTTPS, in addition to whatever HTTP/2.0

Why do some people still consider it a workable idea to just goldplate
SPDY as HTTP/2.0 ?

Isn't the idea to make HTTP/2.0 more desirable than HTTP/1.1 ?

If we don't make it more desirable for the majority of the web,
people will vote with their packets, and HTTP/1.1 will continue to
be the default protocol.  (See also: IPv6)

I propose that we decide, once and for all, that HTTP/2.0, unlike
HTTP/1.1, SHALL be standardized with the expectation and support for
multiple transport protocols, right from the beginning.

And of course HTTP/2.0 should come with a "canonical" TCP based
transport protocol, and of course somebody will push for that being

But such a decision on our part will seem a lot less moronic if
HTTP/2.0 can work with alternative transports.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 25 March 2012 10:59:53 UTC

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