I know you were very excited to remove SPDY support from NGINX, but for
the
next few years there are a lot of devices (mobile devices that can’t
upgrade, end users who aren’t comfortable upgrading, etc) that are not
going to have http/2 support. By removing SPDY support you’ve created a
situation where we either have to penalize those users by forcing them
to
HTTP(S) connections, or we have to forego upgrading NGINX and not offer
HTTP/2.
Cloudflare is offering both SPDY and HTTP/2 - they are a huge NGINX shop
but I’m not clear if they are using NGINX to do that or not. I’d like to
encourage you to follow their lead and reinstate the SPDY support for a
while (even if its just a compile time option thats disabled by
default).
I know you were very excited to remove SPDY support from NGINX, but
for the next few years there are a lot of devices (mobile devices
that can’t upgrade, end users who aren’t comfortable upgrading, etc)
that are not going to have http/2 support. By removing SPDY support
you’ve created a situation where we either have to penalize those
users by forcing them to HTTP(S) connections, or we have to forego
upgrading NGINX and not offer HTTP/2.
I think these “a lot” and “many years” are just overestimation based
on the marketing buzz around spdy, http2 and other so-called
innovations:
As you see, spdy penetration is just 6% and it starts to decline.
http/2 is still ~2% but growing super quickly.
And we do provide 1.8 branch which supports spdy.
Cloudflare is offering both SPDY and HTTP/2 - they are a huge NGINX
shop but I’m not clear if they are using NGINX to do that or not.
I’d like to encourage you to follow their lead and reinstate the
SPDY support for a while (even if its just a compile time option
thats disabled by default).
As for your request: can you explain how spdy deprecation affects you
personally (not Cloudflare or other).
Let me get back to you on that - we’re going to send some traffic
through
Cloudflare and see how the traffic breaks out given the choice of all
three
protocols.
The answer is that there’s a huge difference between patching something
to get some feature for your own build and actually to provide support,
to keep maintaining the code.
We aren’t going to spend more time on maintaining already deprecated
experimental protocol. A lot of work is being done for every release
to find and fix bugs, to implement new features, to test on various
platforms. All these procedures are essentially to provide high quality
product for millions of users around the world with various use cases
and
configurations. Any additional line of code adds additional cost to
this
work.
wbr, Valentin V. Bartenev
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.