Enabling HTTP/2 for Dropbox web services: experiences and observations

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.

> 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.

For a large application, I wonder if you could configure Closure to output multiple files.. Maybe libraries and such in one file and client code in another? I would imagine you could at least split the code there.

I just read the mailing list post that was referenced in the article (http://mailman.nginx.org/pipermail/nginx-devel/2016-May/0082...) and found nginx flow control handling also quite peculiar there. Setting the initial flow control window to 0 and then increasing it based on content-length will increase the latency a lot and opens the window for lots of interoperability bugs. E.g. because the client already starts a stream and sends data (based on the default flow control window), which then gets rejected and which might not be retried (depending on the client libraries implementation).

Would be interesting to know what nginx does when it receives no content-length header, which is also valid.

From reading and implementing the HTTP/2 spec the setttings negotiation is the biggest weak spot in opinion, because it represents a big race condition where the expectations of client and servers probably won't match. I would have preferred it if they would either have put in a mandatory wait for SETTINGS ACK until streams can be acknowledged or if the default settings (window size, HPACK table size) would be very low and could only be increased during negotation. With the given HTTP/2 spec I would most likely try to be conservative as a library or application author and just announce/use the default settings or bigger ones in order to avoid compatibility problems. For most server this should be possible. However for constrained devices lower default settings would have been preferrable.

All major internet protocols to date has been plain text, which for almost anyone has been easy to learn, easy to inspect and diagnose without specialised tools and easy to extend without creating compatibility concerns because of it. We've already seen SPDY be incompatible between its few versions.

Binary ruins that fine tradition for the promise of 0.1% better performance. And I think that's a terrible trade.