SPDY = HTTP/2.0 or not ?

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 ?

Given:

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

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

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

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