Oh so you don't have to patch it manually anymore?

Patch was very stable, no problems and spdy just works.

Apparently work on the patch/module was sponsored by Automattic (WordPress, Matt Mullenweg) so thanks to them and whomever worked on it! Some background here https://barry.wordpress.com/2012/06/16/nginx-spdy-and-automa...

ps. REMEMBER you need openssl 1.0.1 - previous versions will not work with spdy and distributions like CentOS do not come with the newer version. You can switch to the IUS repo in that case http://iuscommunity.org/pages/Repos.html

     rpm -Uvh http://dl.iuscommunity.org/pub/ius/stable/Redhat/6/x86_64/ius-release-1.0-10.ius.el6.noarch.rpm
     yum install yum-plugin-replace
     yum replace openssl --replace-with openssl10

I tripped up on the NPN module when building openssl from source - great tip with the yum replacement installation. Note: you also need to have EPEL installed for the above to work:

    rpm -Uvh http://ftp.heanet.ie/pub/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

Ah I may have had epel enabled already, I think Centos6 even comes with the repo file, you just have to edit to enable it. If not, they run their own mirror so you don't even need to specify one.

   rpm -ivh epel-release-6-8.noarch.rpm

Thanks linking IUS. Having a repo of recent application packages for CentOS will probably make it my go-to server distro.

A few caveats: "Current implementation of SPDY protocol does not support “server push”.

Processing of requests from SPDY connections cannot be rate limited."

http://nginx.org/en/docs/http/ngx_http_spdy_module.html

And SPDY doesn't support caching per default. Well, it's hard.

Can you clarify this statement? Perhaps there's missing context, but as it reads, it seems like a false statement. When I look at chrome://view-http-cache/, I see a bunch of https:// resources for google.com (which are served over SPDY).

For a moment I thought this was the stable branch.

Note to all: This is a development branch release.

"..1.3.x is usable for production anyway (though might break some 3rd party modules due to API changes introduced from time to time)" -- nginx dev team lead at http://mailman.nginx.org/pipermail/nginx/2013-February/03755...

and I believe should read nginx-1.3.15

What is the difference, unless you are not a module author.

The HTTP 2.0 draft is using SPDY as a starting point for "asynchronous connection multiplexing, header compression, and request-response pipelining, while maintaining full backwards compatibility with the transaction semantics of HTTP 1.1"

So while Google may have come up with SPDY, we may get it as part of HTTP 2.0, from a standards organization. So it's not totally in Google's hands. It's being used as a starting point for a standard.

http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/

http://en.wikipedia.org/wiki/HTTP_2.0

> we may get it

Which I think is the key statement here. This is all fantastic work, from both Google and those working on the draft, but this is years from being standardized properly and years more before it's ubiquitous on all browsers.

Also, while its performance is very impressive when comparing against vanilla HTTPS, I haven't seen any impressive numbers of it vs vanilla HTTP?

As far as I understand, it's not necessary to wait until SPDY is ubiquitous on all browsers. By enabling SPDY support in Nginx and setting one header in HTTP responses, you can serve your content via both protocols. Any SPDY-enabled visitors would discover the feature, and switch after the first HTTP request.

On the browser side, Chrome supports SPDY, and has market share of somewhere between 25-50%.

So if I'm not mistaken, enabling this module would make things faster for a large fraction of your visitors, while being backwards-compatible with any browser.

>This is all fantastic work, from both Google and those working on the draft, but this is years from being standardized properly and years more before it's ubiquitous on all browsers.

Just like CSS3 and HTML5. But you can start using it now, all the same, and many people do, all the same.

>Also, while its performance is very impressive when comparing against vanilla HTTPS, I haven't seen any impressive numbers of it vs vanilla HTTP?

It's not supposed to be used with HTTP. And the web of the future is not supposed to have much HTTP without S, either.

Are there any ecommerce sites using SPDY?

Google Wallet: https://www.google.com/wallet/

  window.chrome.loadTimes().wasFetchedViaSpdy

Google Wallet. btw, good work nginx. I'm always interested in you guys' work :)