

Facebook announces SPDY support - igrigorik
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html

======
eliben
It is not what the linked post announces. Quoting:

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

------
kristofferR
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".

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.

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.

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.

~~~
rachelbythebay
I'd hope that anyone speaking SPDY would also be SNI-capable, thus negating
the usual need for one IP+port per certificate.

Granted, it does nothing for your older non-SNI browsers, but they won't be
speaking SPDY or HTTP/2.0 or whatever it winds up being called.

<http://en.wikipedia.org/wiki/Server_Name_Indication>

~~~
notatoad
Android browser supports SPDY but doesn't support SNI.

~~~
agl
Versions of Android that support SPDY also support SNI.

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

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

~~~
snprbob86
I think this is a beautiful example of competition at work. Google Chrome
enabled them to forge ahead of the other browsers to scratch their own itch.
Facebook evaluated their work and it checked out, so it will become the
defecto standard as others join in using it. Thus, standardiztions committees
avoid clean room engineering and instead formalize proven implementations for
broader distribution.

~~~
mnutt
As a side note, "defecto standard" is a great turn of phrase which seems to
never have been used intentionally. Googling it results in pages and pages of
very serious documents which intended to use "de facto standard".

~~~
snprbob86
Really, that was just my iPad and autocorrect, followed by poor editing.

~~~
mnutt
Yeah, I didn't mean to give you a hard time for the ipad autocorrect, I just
thought the end result was funny.

------
metabrew
And here's Twitter's response to the same Expression of Interest too:
[http://lists.w3.org/Archives/Public/ietf-http-
wg/2012JulSep/...](http://lists.w3.org/Archives/Public/ietf-http-
wg/2012JulSep/0250.html)

~~~
Tobu
Twitter is already running SPDY, by the way. Here's a Firefox extension that
shows a little icon on SPDY-enabled sites:
<https://addons.mozilla.org/firefox/addon/spdy-indicator/>

------
wickedchicken
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 _aren't_ served via SSL (I'm
looking at you, Disqus!), then you get the big ugly 'mixed content' warning.

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!

~~~
tonfa
I thought they released ssl for custom domains at IO.

------
nuclear_eclipse
> "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."

What's _more_ lightweight than gzip? DEFLATE?

~~~
reacocard
Snappy is faster than gzip/zlib:

    
    
      "For instance, compared to the fastest mode of zlib, Snappy
      is an order of magnitude faster for most inputs, but the 
      resulting compressed files are anywhere from 20% to 100% 
      bigger."
    

<https://code.google.com/p/snappy/>

------
sathappan
That's great news. But why is that FB's SPDY session never gets captured in
chrome net-internals?

~~~
ehsanu1
From the link:

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

~~~
sathappan
That's great.. Looking forward to it..

------
jebblue
I'm actually a fan of the Trac software linked to in the article. It's hard to
beat a combined Wiki, source browser and ticket management.

------
tysons
a massive gain for FB would be pushing data to the browser rather than pinging
for new data no? SPDY allows this

