Hey,
> I do not favor offering the set of {2,4} - I think that increases the risk
> of spdy/2 becoming a defacto standard which is the biggest risk in this
> process. Skipping revisions sends that signal; imo.
But is this really a bad thing? SPDY/2 is "good enough" and I would like to
see {2,latest} set supported by the browsers for at least a few months after
SPDY gets standardized.
I see two reasons for it:
1) Adoption rate on the server-side is extremely slow.
People just install whatever stable version of the web server is available
in packages from the operating system at the installation / system upgrade
time and then almost never update it.
To put some numbers behind this, I've checked which web servers are powering
TOP30k websites (according to Alexa)... Out of the 30k tested websites 13434
(44.78%) were powered by Apache and 6225 (20.75%) were powered by nginx. Out
of those only 9209 (46.84%) presented full version string that I could match
against release dates.
year | count| percent
----------------------
older | 3239 | 35.17%
2010 | 2264 | 24.58%
2011 | 1466 | 15.92%
2012 | 2240 | 24.32%
----------------------
total | 9209 | 100.00%
As you can see, only ~25% of the servers is using "fairly recent" (2012)
releases and only ~40% of the servers is using "non-ancient" (2011+)
releases.
I expect to see stable releases of Apache & nginx working with SPDY out ot
the box around November/December, maybe later, which means that they would
get deployed and used in production for most of the 2013/2014, which means
that either SPDY/2 or SPDY/3 should be supported by browsers in that
timeframe, otherwise we'll end-up with the situation where most of the web
servers support SPDY/2 and/or SPDY/3, but no browser is negotiating those
versions anymore.
Also, if Chrome is really planning to EOL SPDY/2 in November, then nginx's
SPDY support is virtually dead on arrival.
2) The risk of unexpected transport degradation.
If browsers support only {latest-1,latest} set, then we'll definitely see
situations in which SPDY suddenly stops working without any changes on the
server-side (i.e. web servers with support for {2,3} and browsers moving
from {3,4} to {4,5}).
To make this situation even worse, if people start moving their websites
from HTTP to HTTPS in order to leverage SPDY and improve performance and
then, after months of "fast web", SPDY will unexpectedly stop working, the
performance degradation will be significant (because of the SSL overhead)
and web will become slow for everybody once again.
Hopefully my reasoning is enough to keep SPDY/2 support for a while.
Best regards,
Piotr Sikora <
piotr....@frickle.com >