Comment by bsdetector | Hacker News Reader

Comment by bsdetector | Hacker News Reader

> Be careful with enabling HTTP/2 for everything, especially when you do not control the clients. As HTTP/2 is still relatively new, from our experience, some clients/libraries and server implementations are not fully compatible yet.

One of the main excuses given for not enabling HTTP 1.1 pipelining was a small amount of software that didn't handle it correctly. According to Google, we needed a new protocol so we could start out fresh where there wouldn't be software not implementing the protocol correctly.

But according to this report, the browser with the largest market share and by the creators of HTTP/2 had a bad implementation of it for which a workaround had to be found for.

For history's sake we should recognize now that this buggy software argument for not enabling pipelining was never valid. Not enabling pipelining was used as a political tool to prevent HTTP 1.1 from being on par performance-wise with the new protocol people wanted for other reasons, and that's also why Google never even once tested SPDY against pipelining.

> Not enabling pipelining was used as a political tool to prevent HTTP 1.1 from being on par performance-wise with the new protocol people wanted for other reasons

I'm curious, what are the politics behind this? What are the 'other reasons'?

Google wanting to impose SPDY as a standard and a replacement for HTTP. perhaps.

Google does all sort of weird stuff. I had to disable their QUIC protocol on Chrome because Google apps stopped loading correctly or needed 15 refresh. It was driving me crazy. If some Googlers are listening, your QUIC protocol doesn't work.

Could you report a bug at https://www.chromium.org/for-testers/bug-reporting-guideline... please?

> I'm curious, what are the politics behind this? What are the 'other reasons'?

Google is very good at seeing their own needs and deciding that what is good for them, at their Gigascale, must be good for everyone else on the internet too.

And then they push it in their own products and in their own browser, without any proper concern about internet standards and the processes for being then established in a proper and cooperative way.

Like they did with SPDY, which is now the overly complex and buggy HTTP/2.0.

If they didn't have their own browser, they would not be in a position to do things like this. I sometimes wish for an antitrust case against Google: that they cannot operate the major websites and have their own browser at the same time, much like the ruling against Microsoft over bundling Internet Explorer.

SPDY was developed as an open protocol. It was adopted for HTTP/2 because it was a significant improvement over 1.x.

https://http2.github.io/faq/#whats-the-relationship-with-spd...

Google essentially donated the spec and started phasing out SPDY for HTTP/2, giving up control of it.

How you get "anti-trust case" from this is beyond me. But all of your comments here seem to have an anti-Google slant.

> Google is very good at seeing their own needs and deciding that what is good for them

Even within Google the Chrome team is known to make moves that piss off others at the company. The Chrome/Flash debacle last summer was a good example. The AdX teams, like the rest of the ad industry, were not thrilled with the change being forced on the industry.

They'll be even less happy today [0].

[0] http://arstechnica.com/information-technology/2016/05/html5-...

I'd rather see Sony for owning Bluray as well as media companies, and some of the shady dealings they did with killing HD-DVD.

Nobody else was forced to implement SPDY, and there are plenty of others in the committees that gave us HTTP/2. In the end, it's what we have been saddled with. I would have preferred to see a more streamlined HTTP/2+SSL that didn't have as much round-trip cost. In any case, buggy software happens.

Reply on news.ycombinator.com