[hobohacker]

Speaking as a Chromium SPDY & HTTP/2 developer, we are very much focused on standardization. SPDY is an experimental protocol meant to drive the standards process, not become a de facto standard itself. Therefore, it's critical for us to kill off old SPDY versions.

For more discussion on this topic, please refer to these discussion threads: https://groups.google.com/forum/#!topic/spdy-dev/_uvxTJkeCP0 https://groups.google.com/forum/#!topic/spdy-dev/XDudMZSq3e4

And note that your reference is slightly misleading (I don't think you intended this). It's true, the vast majority of hosts supporting SPDY are running nginx. In practice though, the vast majority of these hosts are Cloudflare or WordPress.com hosted sites. Both run newer versions of nginx with SPDY/3.1 support.

[wbond]

Right, so my point stands that it is interesting that current stable browsers don't support current stable web servers. So unless someone has the resources to test and deploy unstable web servers, it effectively means you shouldn't bother with spdy at this point.

[hobohacker]

I think it's a fair assessment that supporting experimental technologies requires more engineering resources. Everyone has to do the cost/benefit analysis themselves.

[wbond]

You seem intent on arguing about something I have never contested.

I just made the (implied) observation that anyone deploying nginx shouldn't even bother enabling spdy in 1.4 (stable) because effectively nothing will use it anymore. It was something that people who use "stable" software were able to benefit from starting in May 2013, but it is now no longer and won't be again until nginx reaches 1.6. That is, unless spdy/3 is dropped in favor of spdy/4 by then.

(edit: fixed date)

[hobohacker]

Er, I thought I was agreeing with you. What do you think I'm arguing? To be clear, I view these two statements as grounded in the same logic, although perhaps one is more strongly worded than the other:

Yours - "So unless someone has the resources to test and deploy unstable web servers, it effectively means you shouldn't bother with spdy at this point."

Mine - "I think it's a fair assessment that supporting experimental technologies requires more engineering resources. Everyone has to do the cost/benefit analysis themselves."

[wbond]

Let me rephrase then:

Don't even bother building nginx 1.4 with spdy support or configuring it since no one can use it. From May 2013 until now there was a benefit to end-users. There no longer is.

If you want to provide the speed benefits of spdy to users, you now need to run unstable nginx or mod_spdy.

[unethical_ban]

Right. I think the point is that you shouldn't be relying on experimental standards for one's web architecture unless you recognize its experimental status.

[benjamincburns]

As an outside observer, it seems like this kind of pattern happens pretty regularly on HN. It's always kind of funny. There seems to be two distinct flavors:

Pattern 1:

    > Statement
    >> Counterstatement!
    >>> You're saying the same thing.
    >>>> I am? Oh. I *am*. Whoops!

Pattern 2:

    > Statement
    >> Agree with tone of disagreement.
    >>> Disagree on disagreement, while offering up facts to somehow agree *harder*
    >>>> Rebuttal, optional restatement of disagreement, optional statement(s) further
    >>>> reinforcing the common point on which we just can't agree to agree

[barkingcat]

I think for people who actually want spdy3 support, they will evaluate whether nginx 1.5 is stable enough for them. Stable is just a word, and unless it's a straightjacket "stable or nothing" culture you're referring to, yes people will have to make their own decisions about whether 1.5 is stable enough for their needs.

As the posts below, "mainline" is considered stable enough for production.

A rose by any other name?

[wbond]

Well, the difference is that breaking changes are made to 1.5 so when a security update comes out (like today) you have to do regression testing instead of just grabbing and building the latest version.