It is not what the linked post announces. Quoting:<p><i>We currently are implementing SPDY/v2, due to the availability of browser support and the immediate gains we expect to reap. Although we have not run SPDY in production yet, our implementation is almost complete and we feel qualified to comment on SPDY from the implementor's perspective. We are planning to deploy SPDY widely at large scale and will share our deployment experiences as we gain them.</i>
Forced SSL is not a problem for big sites like FB and medium size sites, but it is incredibly problematic for the small sites with less than a couple of thousand visitors per month, in effect it means that SPDY (and eventually HTTP 2.0 unfortunately) will remain a bonus for the elite web sites while the majority of the smaller web sites will remain on HTTP 1.1 "forever".<p>Yeah, I'm aware that some providers like StartSSL hands out free SSL certificates, but I don't think it's a good sign of things to come that you need to hand over sensitive personal information in order to use the latest generation of a fundemental web technology. You'll also need a dedicated IP, which costs money and is becoming increasingly scarce and expensive.<p>I actually run a small web host for my clients and all of them have denied my offer to install a free SSL from StartSSL in order to get SPDY because of the privacy concerns and the extra cost of the dedicated IP they're required to get.<p>It's a shame that a large majority of the web sites on the net will become stuck on an old technology just because of an arbitrary requirement for encryption even though they have nothing to secure anyway.
It's great to see how such a fundamental change in how browsers and servers communicate can get rolled out so quickly! I would have guessed that this sort of thing would require many more years of effort than it did.<p>The author of the post, however, does seem to misunderstand SPDY's server push feature. He states that Facebook requires a substitute for long-polling for low-latency message delivery, and seems to think SPDY provides this. Unless I'm mistaken and there's some Javascript API available, server push is merely for cache-priming and reducing latency of requested objects alongside a regular pageload (eg, push the CSS and images along with an html page).
And here's Twitter's response to the same Expression of Interest too: <a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0250.html" rel="nofollow">http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/...</a>
On a side note: if you use Google AppEngine, you already have SPDY support (as long as you visit your app via SSL, which usually requires the .appspot.com domain). Of course, if some services you use <i>aren't</i> served via SSL (I'm looking at you, Disqus!), then you get the big ugly 'mixed content' warning.<p>Moral of the story: if you run a web service with an API or embedded javascript module, make sure the entire stack can be run over SSL!
> "SPDY's header compression is a good, general-purpose solution, and gzip is a good starting point, but we would prefer to see a more lightweight compression algorithm for the HTTP/2.0 standard."<p>What's <i>more</i> lightweight than gzip? DEFLATE?