11–20 of 21 posts
For a moment I thought this was the stable branch. Note to all: This is a development branch release.
Is anyone going to switch their production setup to run software in development merely to support a "internet-protocol" entirely controlled by a single company known for developing things behind closed doors?
SPDY on the open internet makes no fucking sense.
This is Microsoft and MSIE all over again, but people are evidently too blinded by Google-fandom to realize it.
Are there any ecommerce sites using SPDY?
How real is this interest for Google's non-standard anyway? Is anyone going to switch their production setup to run software in development merely to support a "internet-protocol" entirely controlled by a single company known for developing things behind closed doors? SPDY on the open internet makes no fucking sense. This is Microsoft and MSIE all over again, but people are evidently too blinded by Google-fandom to r…
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.
How real is this interest for Google's non-standard anyway? Is anyone going to switch their production setup to run software in development merely to support a "internet-protocol" entirely controlled by a single company known for developing things behind closed doors? SPDY on the open internet makes no fucking sense. This is Microsoft and MSIE all over again, but people are evidently too blinded by Google-fandom to r…
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 p…
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?
Earlier quoted context omitted.
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 p…
> 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?
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.
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
Earlier quoted context omitted.
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 p…
> 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?
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.
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 distrib…
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 distrib…
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
rpm -ivh epel-release-6-8.noarch.rpm