It's time to begin the long process of unwinding all the hacks that we've built to make HTTP/1.1 fast. No more concatenation of static assets, no more domain sharding.<p>The future looks more like this, as the default, with no special effort required: <a href="https://http2.golang.org/gophertiles" rel="nofollow">https://http2.golang.org/gophertiles</a><p>May nobody else have to suffer through writing an interoperable HTTP/1.1 parser!
I read Daniel Stenberg's (he is a maintainer of curl, I think?) "http2 explained" pdf the other day, and it's by far the best comprehensive explanation of http2 that I have seen. Well worth a read if you're curious what's coming with http2. <a href="http://daniel.haxx.se/http2/" rel="nofollow">http://daniel.haxx.se/http2/</a>
I know I'm apparently not meant to be, but I'm genuinely keen to start using HTTP/2. If you've been following some of the things being done in HTML recently (rel=subresource, rel=dns-prefetch), I think it's starting to become a little obvious that for most people HTTP is the bottleneck. HTTP/2 seems to be a good, solid step forwards. If it's not perfect, well, it doesn't have to be; 2 isn't the last number.
this seems nice, pretty conservative.<p><a href="https://tools.ietf.org/html/draft-ietf-httpbis-http2-17" rel="nofollow">https://tools.ietf.org/html/draft-ietf-httpbis-http2-17</a><p>"<p>Abstract<p><pre><code> This specification describes an optimized expression of the semantics
of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more
efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple
concurrent exchanges on the same connection. It also introduces
unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
</code></pre>
"<p>all these changes seem good without a large change, just an improved user experience. (the Introduction section is also good - "HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection", I'd quote more but why not click through the link at the top of this comment. basically just some compression of headers, none of the funky stuff to keep connections alive for server push, prioritizing important requests, etc. all without changing semantics much - great.)
Does anyone have any information about HTTP/2 development in Apache? Searching the bug list I don't immediately see anything and the only thing I can find from a Google search is a mailing list entry with someone asking about http/2 development and being told that it isn't really being worked on [1]<p>[1] <a href="http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mbox/%3CCALK=YjONaJzKsYouzrYJrhT=ZXW6oHbZCgtBH9nfi5wuP=qwDw@mail.gmail.com%3E" rel="nofollow">http://mail-archives.apache.org/mod_mbox/httpd-dev/201408.mb...</a>
I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.
Stupid question: would you rather have server push serving static content from the application server or a CDN for the static assets? If a CDN, how can server push be leveraged when the assets are not related to each others (and the server can't tell in which order they will be requested).
Question: I originally heard HTTP/2 would force TLS and have it baked into the protocol. Is this still the case? If so, is this going to be strictly enforced? I think it's a really terrible idea to melt a protocol and a transport together. Or am I misunderstanding how it works?
I'd really like to know what this means in the context of MeteorJS - particularly how the HTTP Push feature will affect MeteorJS in the long run. Does it make MeteorJS redundant?
[placeholder for commentary about how HTTP/2 is a bad protocol because it's binary and everything could have been fixed in a text protocol follow by ad nauseum repetition of all the same old arguments]
HTTP/2 is a bad protocol, that much is clear by now. Luckily most of us won't have to deal with it, because it will be deployed merely as an optimization, with a new generation of reverse-proxy servers, like H2O. <a href="https://github.com/h2o/h2o" rel="nofollow">https://github.com/h2o/h2o</a>