Hello,
after seeing all the disagreements that were expressed on the list these
days (including from me) about what feature from SPDY we'd like to have
mandatory or not in HTTP, I'm thinking that part of the issue comes from
the fact that there are a number of different usages of HTTP right now,
all of them fairly legitimate.
First I think that everyone here agrees that something needs to be done
to improve end user experience especially in the mobile networks. And
this is reflected by all proposals, including the http-ng draft from
14 years ago!
Second, the privacy issues are a mess because we try to address a social
problem by technical means. It's impossible to decide on a protocol if
we all give an example of what we'd like to protect and what we'd prefer
not to protect because it is useless and possibly counter-productive.
And precisely, some of the disagreement comes from the fact that we're
trying to see these impacts on the infrastructure we know today, which
would obviously be a total breakage. As PHK said it, a number of sites
will not want to afford crypto for privacy. I too know some sites which
would significantly increase their operating costs by doing so. But
what we're designing is not for now but for tomorrow.
What I think is that anyway we need a smooth upgrade path from current
HTTP/1.1 infrastructure and what will constitute the web tomorrow without
making any bigbang.
SPDY specifically addresses issues observed between the browser and the
server-side infrastructure. Some of its mandatory features are probably
not desirable past the server-side frontend *right now* (basically
whatever addresses latency and privacy concerns). Still, it would be
too bad not to make the server side infrastructure benefit from a good
lifting by progressively migrating from 1.1 to 2.0.
What does this mean ? Simply that we have to consider HTTP/2.0 as a
subset of SPDY or that SPDY should be an add-on to HTTP. And that
makes a lot of sense. First, SPDY already is an optimized messaging
alternative to HTTP. It carries HTTP/1.1, it can as well carry HTTP/2.0
since we're supposed to maintain compatible semantics.
We could then get to a point where :
- an http:// scheme indicates a connection to HTTP/1.x or 2.x server
- an https:// scheme indicates a connection to HTTP/1.x or 2.x server
via an SSL/TLS layer
- a spdy:// scheme indicates a connection to HTTP/1.x or 2.x server
via a SPDY layer
By having HTTP/2.0 upgradable from 1.1, this split is natural :
+----------------------------+
| Application |
+----+-----------------------+
| WS | HTTP/2.0 |
+----+--------------+ |
| HTTP/1.1 | |
| +-----+---+--------+
| | TLS | SPDY |
+---------+-----+------------+ server-side
^ ^ ^
| | |
| | |
| | |
+---------+-----+------------+ user-agent
| | TLS | SPDY |
| +-----+-------+----+
| HTTP/1.1, 2.0 | |
+-------------------+---+ |
| | WS |
| Applications +--------+
| |
+----------------------------+
The upgrade path would then be much easier :
1) have browsers, intermediaries and servers progressively
adopt HTTP/2.0 and support a seamless upgrade
2) have browsers, some intermediaries and some servers
progressively adopt SPDY for the front-line
3) have a lot of web sites offer URLs as spdy:// instead of http://,
and implement mandatory redirects from http:// to spdy:// like a
few sites are currently doing (eg: twitter)
4) have browsers at some point use the SPDY as the default scheme
for any domain name typed on the URL bar.
5) have browsers at one point disable by default transparent support
for the old http:// scheme (eg: put a warning or have to tweak
some settings for this). This will probably 10-20 years from now.
Before we get to point 5, we'd have a number of sites running on the
new protocol, with an efficient HTTP/2.0 deployed at many places
including the backoffice, and with SPDY used by web browsers for
improved performance/privacy. That will not prevent specific agents
from still only using a simpler HTTP/2.0 for some uses.
So I think that what we should do is to distinguish between what is
really desirable to have in HTTP and what is contentious. Everything
which increases costs or causes trouble for *some* use cases should
not be mandatory in HTTP but would be in the SPDY layer (as it is
today BTW).
I think that the current SPDY+HTTP mix has shown that the two protocols
are complementary and can be efficient together. Still we can significantly
improve HTTP to make both benefit from this, starting with the backoffice
infrastructure where most of the requests lie.
Willy