11 ms·

HTTP/2 is not the future, it’s the present

185 points by Eleven_Wilson 10y ago

merb 10y ago
and it's not as good as it could've be. the statefulness makes it really really really really really akward.
- blowski 10y ago
  I haven't worked with HTTP2 much - I thought it was still stateless. Are you referring to HPACK?
  - merb 10y ago
    http://httpwg.org/specs/rfc7540.html#StreamStates http://httpwg.org/specs/rfc7540.html#StreamStates
    - lclarkmichalek 10y ago
      Man, just wait till you see the equivalent diagram for TCP.
      - jsnell 10y ago
        The equivalent RFC 793 diagram isn't that much more complex. It only gets properly messy once you look at the real TCP state transitions: https://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf https://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf
- sametmax 10y ago
  HTTP2 has been created for big players. When you are a small team, benefits from it are not that interesting. Plus mandatory TLS is making boostraping a project unnecessary hard.
  - fredsir 10y ago
    If you mean bootstrapping a webservice-project, I don't believe it's hard in any way. With offerings like Lets Encrypts, it's incredibly easy and takes no more than 20 minutes.
    - dijit 10y ago
      Bootstrapping using letsecrypt requires an internet connection and a public facing service. I can say that 14 year old me, who had books, a pc and no internet would have been screwed by this.
      - icebraining 10y ago
        If you're just using it locally, you can use a self-signed cert. Caddy generates one automatically by just adding "self_signed" to your config[1]. Or you can copy-paste a single OpenSSL or PowerShell command to generate one. [1]: https://caddyserver.com/blog/caddy-0_9-released#easy-self-signed-certificates https://caddyserver.com/blog/caddy-0_9-released#easy-self-si...
        drcongo 10y ago
        I tried out Caddy on a project the other day, it was incredibly simple to set up HTTP2 with Let's Encrypt.
        dijit 10y ago
        This is the closest thing to reasonable that anybody has suggested. I seem to be getting brigaded by the encryption cargo cult and while I agree that nothing public facing should not have encryption it's a different thing to force all developing students to learn TLS/SSL before they start actually learning to code. I expressed dissatisfaction with the fact that learning to code for the web has a barrier to entry now that can be very difficult for various reasons. Learning To debug TLS issues is another problem in of itself which often takes a lot of years to fully understand. A new programmer should be very aware of the tools that are available to make this easier. But 14 year old me with a php book and no internet did not have such luxuries and that was all I said.
- olavgg 10y ago
  Agreed, I think PHK nails his concerns here: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html
- merb 10y ago
  btw. I don't talk about the forced TLS stuff. besides I'm working in a company who sells boxes for intranet's (where deploying TLS for domains is not always easy, lack of proper DNS or other things, etc...) The spec has just a lot of edge cases especially when handling state/what exactly is a specification violation. Especially handling clients who opened a connection and now are in closing state, can be really really tricky to handle. On the implementation side the Statefulness adds a lot of overhead, that HTTP/1.1 did not had (besides other flaws) I think HTTP/2 was a little bit rushed, but I guess HTTP/3 will clean up some stuff.
rita3ko 10y ago
It's not Eleven-Lab's present, seeing as they don't support HTTPS, and HTTP2 doesn't work without it.
- lumisota 10y ago
  The standard [1] doesn't require the use of TLS/HTTPS. However, all of the major implementations only support HTTP/2 over TLS. [1] RFC7540 - https://tools.ietf.org/html/rfc7540 https://tools.ietf.org/html/rfc7540
  - rita3ko 10y ago
    Correct, "all of the major implementations" :)
    - frik 10y ago
      Which I'd quite bad. I don't understand why/who lobbied to implement it that way in Firefox. Can someone disclose the decision-making behind this? It would help devs a lot if HTTP/2 works without TLS too.
      - Twirrim 10y ago
        All the main browsers want to encourage HTTPS everywhere. They're taking a number of initiatives to encourage it, some are carrots, some are sticks. Mostly it's ending up as the stick, eg "You can only get these major performance advantages over HTTPS". Soon there is an intent to specifically call out non-HTTPS content very prominently in the browser, even more so that HTTPS content was ever called out back when that was introduced.
        frik 10y ago
        Yes, exactly. But why? What's the agenda? Why now? It's not like Amazon.com was broken between 1996 and 2016. There is a push to HTTPS at all costs, even if things (ad networks, devs, software) is not ready and is there even a need for 100% TLS? That an open source browser is engaged in such initiative is not good. With HTTP you can be anonymous, and most website visits aren't mission critical things. With HTTPS your traffic is quite unique and the players with big money have the resources anyway, there TLS is no big thing as we learned in the last few years. So which Think-tank or what ever is behind this initiative?
magicbuzz 10y ago
To be clear, Server Push as described in the article is not actually provided by nginx yet and thus by the server config in the article. I have no doubt that the awesome nginx folks will implement in due time though.
- avichalp 10y ago
  Its implementation is already present in nginx plus since 2015. https://www.nginx.com/blog/http2-r7/ https://www.nginx.com/blog/http2-r7/ Not sure if they are going to provide server pushes in the community version soon.
  - juliangoldsmith 10y ago
    From your link: >The “Server Push” feature defined in the HTTP/2 RFC is not supported in this release. Future releases of NGINX Plus might include it.
    - scardine 10y ago
      Does not invalidate his main point: the developers have a conflict of interest into releasing features for the open source version that competes with the paid version.
      - juliangoldsmith 10y ago
        My reply wasn't intended to. I was pointing out that even the Plus version doesn't have Server Push. I don't expect it will ever be present in the open source version, barring a fork.
- pcollins123 10y ago
  I'm not sure they will ever implement it actually. Nginx does not support HTTP/2 server push as of March 2017 (v1.11). Owen Garrett at nginx has summarized the reasons as follows: - it is a non-essential and optional part of http/2 - if the client already has the resource cached, then by pushing it to them you might be unnecessarily wasting bandwidth. - server push spec might change in the future. - Link headers as hints is useful, but usage has been low from web developers. - server push has been available as part of SPDY and was not utilized by many web developers. Read his original comments here[1]. This table[2] accurately describes the pro's and con's of server hints vs server push. Personally this disappoints me because I think this would be a valuable feature for web developers willing to invest the time to optimize page speeds. I also know that some large CDN's like Cloudflare have implemented their own version within nginx to optimize page downloads. [1]: https://www.nginx.com/blog/http2-r7/ https://www.nginx.com/blog/http2-r7/ [2]: https://www.chromium.org/spdy/link-headers-and-server-hint https://www.chromium.org/spdy/link-headers-and-server-hint
yoavm 10y ago
This just made me add the 'http2' directive to my Nginx configs, and it seems that I'm getting a 15% decrease of loading time for my websites. Should have done this long ago...
- pixl97 10y ago
  Just to be sure, use a site like ssllabs.com to make sure you are actually using an ALPN. For example on Ubuntu 14, setting http2 does nothing, as it requires Openssl 1.0.2. If you are using Ubuntu 16, or a distro that provides the newer Openssl it should work correctly.
- Dylan16807 10y ago
  It's quite useful, I just wish it wouldn't segfault my apache processes.
solidr53 10y ago
Can somebody ask mr. Heroku why they don't support it...
- 6t6t6t6 10y ago
  You should probably not be serving a site directly from Heroku anyway. Put Cloudflare in front of your Heroku and you will get HTTP2
TazeTSchnitzel 10y ago
> Remember, in may 1996, the very first HTTP protocol version (HTTP/1.0) was born. Uh, what? HTTP predates 1996. The first version was HTTP/0.9, from 1991. 0.9 is still supported by a lot of web servers, too!
- hdhzy 10y ago
  And browsers! Causing interesting bugs: https://bugs.chromium.org/p/chromium/issues/detail?id=669800 https://bugs.chromium.org/p/chromium/issues/detail?id=669800
  - kupiakos 10y ago
    Wow, that's a disaster. Hopefully it was a wake-up call to the Shoutcast administrators to not depend on 10+ year old software that doesn't follow actual standards.
    - kuschku 10y ago
      You mean, you expect tenthousands of broadcasters, with millions of users, to switch their systems over, because some people at Google decided that they should control the web? It's very questionable that such a move can even be made without a discussion in one of the web standards groups, and can be made entirely by Google employees. In the long term, changing this is unavoidable, but without warning, and without discussion, deprecating a widely used standard is not exactly awesome. You'd expect such a change to require discussion in standards groups, months of warnings before it happens, etc
      - Chronos 10y ago
        Anyone who depends on the Internet for their business should know better than to run 10 year old unpatched Internet server software.
        kuschku 10y ago
        You mean, a 10 year old, unpatched protocol. You don't know the actual software running behind it, and how they might have modified it. And just deprecating an entire category of protocols still in use without Google even sending an email as warning to the servers that still use it, well, that’s insane.
cagenut 10y ago
Anyone combining h2o and node in interesting ways they'd like to share/blog-about yet?
cflat 10y ago
As I've said previously [1][2][3], you shouldn't PUSH with `Link re="preload"` for performance gains. You will likely run into TCP HOL Blocking or browser request race conditions. Instead send PUSH_PROMISES in the whitespace while the client waits for the TTFB. [1] https://news.ycombinator.com/item?id=14082636 https://news.ycombinator.com/item?id=14082636 [2] https://shouldipush.com https://shouldipush.com [3] https://youtu.be/GjWD1pOkxUk?t=1534 https://youtu.be/GjWD1pOkxUk?t=1534
webo 10y ago
Is the common pattern to support http2 at the highest level? If a request goes through CDN/edge network -> Load Balancer -> nginx -> Python app, should http2 be enabled on all components or is enabling just on the CDN enough? Any pros/cons? With HTTPS, usually enabling on the CDN is good enough for most cases.
- bluejekyll 10y ago
  That will only get you the protocol. All of the server push stuff for example, needs to be supported by the actual web server.
  - luhn 10y ago
    No, a CDN can support HTTP/2 server push on it's own. For example, https://www.cloudflare.com/website-optimization/http2/serverpush/ https://www.cloudflare.com/website-optimization/http2/server...
  - predakanga 10y ago
    That's not correct - while any HTTP/2 capable servers along the path may implement server push, the most important one is the closest server to the user (i.e. the CDN). The only requirement is that the intermediate servers must not strip out the server push headers/tags, so that the edge server knows what to actually push. It's quite possible to have your own server provide HTTP/1.1 and still take advantage of server push, and this is a usecase supported by Akamai[1], Cloudflare[2], and I suspect other CDNs (can't find details) - you may get better performance using HTTP/2 on that intermediate link, but that's less likely to be because of server push. [1]: https://blogs.akamai.com/2016/04/are-you-ready-for-http2-server-push.html https://blogs.akamai.com/2016/04/are-you-ready-for-http2-ser... [2]: https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ https://blog.cloudflare.com/announcing-support-for-http-2-se...
    - bluejekyll 10y ago
      Ah yes. For static content your correct. I've got my head in dynamic stuff at the moment. Of course you're right.
6t6t6t6 10y ago
I'd like to see a web framework that implements well HTTP2. AFAIK, the Assets Pipeline in Rails is not designed for HTTP2 and I think that there are no immediate plans to implement it.
- chucke 10y ago
  > AFAIK, the Assets Pipeline in Rails is not designed for HTTP2... Not true. You can define as many manifests as you want, and design your own heuristics around resources in rails. It doesn't need to be an HTTP feature. You have to patch rails to fill up the link header with the assets however. If you do it, proper reverse proxies like h2o can serve assets using server push.
  - 6t6t6t6 10y ago
    > You have to patch rails That sounds like a bad idea in the long term... ;)
daphreak 10y ago
While I look forward to a faster desktop and mobile browsing experience with HTTP/2 I do worry about the complexity. I hope that the simpler protocols remain supported for a long time to enable implementations on low resource embedded systems. The last thing we need is for all the closed-source, internet-connected, black boxes in our lives to poorly implement a complicated web standard protocol. There are so many places where we have already seen vulnerabilities with implementations of simple web severs and clients.
- MichaelGG 10y ago
  What looks particularly complex about HTTP/2? The "simple" text based protocols are NOT simple to implement correctly. Go try out line-wrapping and play with using \r\n vs \r vs \n as line endings and tell me what the compatibility ends up like. And this does create real-world security problems. Some VoIP companies allow you to make free calls by screwing with their SIP proxies because popular software handles line endings differently allowing you to make their edge software interpret packets differently than their core. Even parsing is easier in a nice binary format (and much, much, faster, too).
  - ris 10y ago
    It's not got much to do with the serialization protocol itself as such - most server software uses a library which handles it properly and then doesn't have to worry about it. It's more that web developers have to get bits of their stack (the dynamic and static serving aspects) to cooperate in ways they never had to before (in fact, the general wisdom was to separate them as much as possible as they have totally different requirements when it comes to performant serving). This is not even to get into persistent connections & server push etc., which is quite a big subject for developers used to handling independent fire-and-forget requests. I guess I'm saying the massively complexity comes in trying to use these new features.
KirinDave 10y ago
I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs. Right now, everyone who's supported both mobile and web APIs (or cared about bandwidth constraint) can tell you how frustrating it is that well factored restful (or rest-ish) APIs are often the casualty of accepting the realities in mobile client support. You end up increasingly collapsing requests into one Special Bigger Request because One Special Bigger Request almost always has better performance on bandwidth-constrained clients than the same performance elsewhere. And this is especially frustrating because often times the client can't tell us exactly what they need in the initial request. The best we often can do is stash an etags header in the request and try and get very fancy there. We end up with smarter endpoints which require tons more programmer maintenance, and move us away from the world of autogenerated and automatically audited endpoints. HTTP/2 w/ Push offers us a way to split the difference. While individual endpoints can be served very quickly, we can have our APIs recognize (via etags, probabilistic inference, previous negotiation, etc) that more data is about to be requested and push it immediately. This means we can keep our well-factored, simple API designs that we developed 10 years ago without sacrificing performance to the bandwidth-constrained. It means that we can further lean on the abstraction Service Worker gives us in web clients to just naively poll in client code and trust in clientside caching to make this efficient (with the fallback being the same network call we would have always made). It's why I'm absolutely infuriated with so many languages for balking at supporting HTTP/2 as part of their stack (more often than not, on the grounds that SSL + ALPN seems tedious to implement).
- renke1 10y ago
  I agree with everything you said. One thing though, I think "One Special Bigger Request" still makes sense in a lot of situation where you have some kind of "transaction" going on. I often encountered code that calls multiple HTTP endpoints and a failure in one of those requests would actually lead to inconsistent data in the backend. This code is pretty common because many developers assume that requests never fail.
  - KirinDave 10y ago
    Transactional mutations have to have a commit phase. I agree.
tabeth 10y ago
Can someone recommend an up-to-date book/guide on HTTP(2)? I'm thinking this may do: https://http2.github.io/ https://http2.github.io/, but I'm not sure if that's the best guide. Much of the jargon in the comments is unknown to me. The article in the OP is a good start.
- shurcooL 10y ago
  I've learned most things about HTTP/2 from talks given by Brad Fitzpatrick. Go's HTTP/2 support in standard library was largely implemented by him.
spankalee 10y ago
For those interested in HTTP/2 Push, check out Eric Bidelman's Push Manifest format[1], which is a JSON format describing the dependencies to push for any request URL. You can generate the manifest by hand or with tools, and then there are servers that can read the manifest and push the right resources.[2] In Polymer we're most of the way done with support for automatically generating push manifests from a dependency analysis of your project[3] and have push manifest support in our dev server and soon a small production server, so you can `polymer deploy` and get a push-enabled site. [1]: https://github.com/GoogleChrome/http2-push-manifest https://github.com/GoogleChrome/http2-push-manifest [2]: https://github.com/GoogleChrome/http2push-gae https://github.com/GoogleChrome/http2push-gae [3]: https://github.com/Polymer/polymer-build/pull/172 https://github.com/Polymer/polymer-build/pull/172
- pcollins123 10y ago
  This is really interesting thanks. Doesn't this lead to the most highly used static assets being pushed for every subsequent request? Isn't that wasteful? I use varnish cache extensively and am considering writing a probabilistic server push module. It could keep track of subsequent requests and push the next set of assets. This is more of a server module approach rather than client side. Any thoughts on that?
ElijahLynn 10y ago
Worth watching: https://www.youtube.com/watch?v=CkFEoZwWbGQ https://www.youtube.com/watch?v=CkFEoZwWbGQ (HTTP/2: What no one is telling you by Hooman Beheshti @ Fastly) tldr; H2 can be slower than H1.1 under degraded network connections. e.g. mobile connections with high packet loss.
treve 10y ago
It's here, but current server-side implementations are super weak. rel="preload" is a hack. Only the few languages that have a native HTTP 2 push api are really here.

185 points by Eleven_Wilson 10y ago

merb 10y ago

and it's not as good as it could've be. the statefulness makes it really really really really really akward.

blowski 10y ago
I haven't worked with HTTP2 much - I thought it was still stateless. Are you referring to HPACK?
- merb 10y ago
  http://httpwg.org/specs/rfc7540.html#StreamStates http://httpwg.org/specs/rfc7540.html#StreamStates
  - lclarkmichalek 10y ago
    Man, just wait till you see the equivalent diagram for TCP.
    - jsnell 10y ago
      The equivalent RFC 793 diagram isn't that much more complex. It only gets properly messy once you look at the real TCP state transitions: https://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf https://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf
sametmax 10y ago
HTTP2 has been created for big players. When you are a small team, benefits from it are not that interesting. Plus mandatory TLS is making boostraping a project unnecessary hard.
- fredsir 10y ago
  If you mean bootstrapping a webservice-project, I don't believe it's hard in any way. With offerings like Lets Encrypts, it's incredibly easy and takes no more than 20 minutes.
  - dijit 10y ago
    Bootstrapping using letsecrypt requires an internet connection and a public facing service. I can say that 14 year old me, who had books, a pc and no internet would have been screwed by this.
    - icebraining 10y ago
      If you're just using it locally, you can use a self-signed cert. Caddy generates one automatically by just adding "self_signed" to your config[1]. Or you can copy-paste a single OpenSSL or PowerShell command to generate one. [1]: https://caddyserver.com/blog/caddy-0_9-released#easy-self-signed-certificates https://caddyserver.com/blog/caddy-0_9-released#easy-self-si...
      - drcongo 10y ago
        I tried out Caddy on a project the other day, it was incredibly simple to set up HTTP2 with Let's Encrypt.
      - dijit 10y ago
        This is the closest thing to reasonable that anybody has suggested. I seem to be getting brigaded by the encryption cargo cult and while I agree that nothing public facing should not have encryption it's a different thing to force all developing students to learn TLS/SSL before they start actually learning to code. I expressed dissatisfaction with the fact that learning to code for the web has a barrier to entry now that can be very difficult for various reasons. Learning To debug TLS issues is another problem in of itself which often takes a lot of years to fully understand. A new programmer should be very aware of the tools that are available to make this easier. But 14 year old me with a php book and no internet did not have such luxuries and that was all I said.
olavgg 10y ago
Agreed, I think PHK nails his concerns here: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html
merb 10y ago
btw. I don't talk about the forced TLS stuff. besides I'm working in a company who sells boxes for intranet's (where deploying TLS for domains is not always easy, lack of proper DNS or other things, etc...) The spec has just a lot of edge cases especially when handling state/what exactly is a specification violation. Especially handling clients who opened a connection and now are in closing state, can be really really tricky to handle. On the implementation side the Statefulness adds a lot of overhead, that HTTP/1.1 did not had (besides other flaws) I think HTTP/2 was a little bit rushed, but I guess HTTP/3 will clean up some stuff.

rita3ko 10y ago

It's not Eleven-Lab's present, seeing as they don't support HTTPS, and HTTP2 doesn't work without it.

lumisota 10y ago
The standard [1] doesn't require the use of TLS/HTTPS. However, all of the major implementations only support HTTP/2 over TLS. [1] RFC7540 - https://tools.ietf.org/html/rfc7540 https://tools.ietf.org/html/rfc7540
- rita3ko 10y ago
  Correct, "all of the major implementations" :)
  - frik 10y ago
    Which I'd quite bad. I don't understand why/who lobbied to implement it that way in Firefox. Can someone disclose the decision-making behind this? It would help devs a lot if HTTP/2 works without TLS too.
    - Twirrim 10y ago
      All the main browsers want to encourage HTTPS everywhere. They're taking a number of initiatives to encourage it, some are carrots, some are sticks. Mostly it's ending up as the stick, eg "You can only get these major performance advantages over HTTPS". Soon there is an intent to specifically call out non-HTTPS content very prominently in the browser, even more so that HTTPS content was ever called out back when that was introduced.
      - frik 10y ago
        Yes, exactly. But why? What's the agenda? Why now? It's not like Amazon.com was broken between 1996 and 2016. There is a push to HTTPS at all costs, even if things (ad networks, devs, software) is not ready and is there even a need for 100% TLS? That an open source browser is engaged in such initiative is not good. With HTTP you can be anonymous, and most website visits aren't mission critical things. With HTTPS your traffic is quite unique and the players with big money have the resources anyway, there TLS is no big thing as we learned in the last few years. So which Think-tank or what ever is behind this initiative?

magicbuzz 10y ago

To be clear, Server Push as described in the article is not actually provided by nginx yet and thus by the server config in the article. I have no doubt that the awesome nginx folks will implement in due time though.

avichalp 10y ago
Its implementation is already present in nginx plus since 2015. https://www.nginx.com/blog/http2-r7/ https://www.nginx.com/blog/http2-r7/ Not sure if they are going to provide server pushes in the community version soon.
- juliangoldsmith 10y ago
  From your link: >The “Server Push” feature defined in the HTTP/2 RFC is not supported in this release. Future releases of NGINX Plus might include it.
  - scardine 10y ago
    Does not invalidate his main point: the developers have a conflict of interest into releasing features for the open source version that competes with the paid version.
    - juliangoldsmith 10y ago
      My reply wasn't intended to. I was pointing out that even the Plus version doesn't have Server Push. I don't expect it will ever be present in the open source version, barring a fork.
pcollins123 10y ago
I'm not sure they will ever implement it actually. Nginx does not support HTTP/2 server push as of March 2017 (v1.11). Owen Garrett at nginx has summarized the reasons as follows: - it is a non-essential and optional part of http/2 - if the client already has the resource cached, then by pushing it to them you might be unnecessarily wasting bandwidth. - server push spec might change in the future. - Link headers as hints is useful, but usage has been low from web developers. - server push has been available as part of SPDY and was not utilized by many web developers. Read his original comments here[1]. This table[2] accurately describes the pro's and con's of server hints vs server push. Personally this disappoints me because I think this would be a valuable feature for web developers willing to invest the time to optimize page speeds. I also know that some large CDN's like Cloudflare have implemented their own version within nginx to optimize page downloads. [1]: https://www.nginx.com/blog/http2-r7/ https://www.nginx.com/blog/http2-r7/ [2]: https://www.chromium.org/spdy/link-headers-and-server-hint https://www.chromium.org/spdy/link-headers-and-server-hint

yoavm 10y ago

This just made me add the 'http2' directive to my Nginx configs, and it seems that I'm getting a 15% decrease of loading time for my websites. Should have done this long ago...

pixl97 10y ago
Just to be sure, use a site like ssllabs.com to make sure you are actually using an ALPN. For example on Ubuntu 14, setting http2 does nothing, as it requires Openssl 1.0.2. If you are using Ubuntu 16, or a distro that provides the newer Openssl it should work correctly.
Dylan16807 10y ago
It's quite useful, I just wish it wouldn't segfault my apache processes.

solidr53 10y ago

Can somebody ask mr. Heroku why they don't support it...

6t6t6t6 10y ago
You should probably not be serving a site directly from Heroku anyway. Put Cloudflare in front of your Heroku and you will get HTTP2

TazeTSchnitzel 10y ago

> Remember, in may 1996, the very first HTTP protocol version (HTTP/1.0) was born. Uh, what? HTTP predates 1996. The first version was HTTP/0.9, from 1991. 0.9 is still supported by a lot of web servers, too!

hdhzy 10y ago
And browsers! Causing interesting bugs: https://bugs.chromium.org/p/chromium/issues/detail?id=669800 https://bugs.chromium.org/p/chromium/issues/detail?id=669800
- kupiakos 10y ago
  Wow, that's a disaster. Hopefully it was a wake-up call to the Shoutcast administrators to not depend on 10+ year old software that doesn't follow actual standards.
  - kuschku 10y ago
    You mean, you expect tenthousands of broadcasters, with millions of users, to switch their systems over, because some people at Google decided that they should control the web? It's very questionable that such a move can even be made without a discussion in one of the web standards groups, and can be made entirely by Google employees. In the long term, changing this is unavoidable, but without warning, and without discussion, deprecating a widely used standard is not exactly awesome. You'd expect such a change to require discussion in standards groups, months of warnings before it happens, etc
    - Chronos 10y ago
      Anyone who depends on the Internet for their business should know better than to run 10 year old unpatched Internet server software.
      - kuschku 10y ago
        You mean, a 10 year old, unpatched protocol. You don't know the actual software running behind it, and how they might have modified it. And just deprecating an entire category of protocols still in use without Google even sending an email as warning to the servers that still use it, well, that’s insane.

cagenut 10y ago

Anyone combining h2o and node in interesting ways they'd like to share/blog-about yet?

cflat 10y ago

As I've said previously [1][2][3], you shouldn't PUSH with `Link re="preload"` for performance gains. You will likely run into TCP HOL Blocking or browser request race conditions. Instead send PUSH_PROMISES in the whitespace while the client waits for the TTFB. [1] https://news.ycombinator.com/item?id=14082636 https://news.ycombinator.com/item?id=14082636 [2] https://shouldipush.com https://shouldipush.com [3] https://youtu.be/GjWD1pOkxUk?t=1534 https://youtu.be/GjWD1pOkxUk?t=1534

webo 10y ago

Is the common pattern to support http2 at the highest level? If a request goes through CDN/edge network -> Load Balancer -> nginx -> Python app, should http2 be enabled on all components or is enabling just on the CDN enough? Any pros/cons? With HTTPS, usually enabling on the CDN is good enough for most cases.

bluejekyll 10y ago
That will only get you the protocol. All of the server push stuff for example, needs to be supported by the actual web server.
- luhn 10y ago
  No, a CDN can support HTTP/2 server push on it's own. For example, https://www.cloudflare.com/website-optimization/http2/serverpush/ https://www.cloudflare.com/website-optimization/http2/server...
- predakanga 10y ago
  That's not correct - while any HTTP/2 capable servers along the path may implement server push, the most important one is the closest server to the user (i.e. the CDN). The only requirement is that the intermediate servers must not strip out the server push headers/tags, so that the edge server knows what to actually push. It's quite possible to have your own server provide HTTP/1.1 and still take advantage of server push, and this is a usecase supported by Akamai[1], Cloudflare[2], and I suspect other CDNs (can't find details) - you may get better performance using HTTP/2 on that intermediate link, but that's less likely to be because of server push. [1]: https://blogs.akamai.com/2016/04/are-you-ready-for-http2-server-push.html https://blogs.akamai.com/2016/04/are-you-ready-for-http2-ser... [2]: https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ https://blog.cloudflare.com/announcing-support-for-http-2-se...
  - bluejekyll 10y ago
    Ah yes. For static content your correct. I've got my head in dynamic stuff at the moment. Of course you're right.

6t6t6t6 10y ago

I'd like to see a web framework that implements well HTTP2. AFAIK, the Assets Pipeline in Rails is not designed for HTTP2 and I think that there are no immediate plans to implement it.

chucke 10y ago
> AFAIK, the Assets Pipeline in Rails is not designed for HTTP2... Not true. You can define as many manifests as you want, and design your own heuristics around resources in rails. It doesn't need to be an HTTP feature. You have to patch rails to fill up the link header with the assets however. If you do it, proper reverse proxies like h2o can serve assets using server push.
- 6t6t6t6 10y ago
  > You have to patch rails That sounds like a bad idea in the long term... ;)

daphreak 10y ago

While I look forward to a faster desktop and mobile browsing experience with HTTP/2 I do worry about the complexity. I hope that the simpler protocols remain supported for a long time to enable implementations on low resource embedded systems. The last thing we need is for all the closed-source, internet-connected, black boxes in our lives to poorly implement a complicated web standard protocol. There are so many places where we have already seen vulnerabilities with implementations of simple web severs and clients.

MichaelGG 10y ago
What looks particularly complex about HTTP/2? The "simple" text based protocols are NOT simple to implement correctly. Go try out line-wrapping and play with using \r\n vs \r vs \n as line endings and tell me what the compatibility ends up like. And this does create real-world security problems. Some VoIP companies allow you to make free calls by screwing with their SIP proxies because popular software handles line endings differently allowing you to make their edge software interpret packets differently than their core. Even parsing is easier in a nice binary format (and much, much, faster, too).
- ris 10y ago
  It's not got much to do with the serialization protocol itself as such - most server software uses a library which handles it properly and then doesn't have to worry about it. It's more that web developers have to get bits of their stack (the dynamic and static serving aspects) to cooperate in ways they never had to before (in fact, the general wisdom was to separate them as much as possible as they have totally different requirements when it comes to performant serving). This is not even to get into persistent connections & server push etc., which is quite a big subject for developers used to handling independent fire-and-forget requests. I guess I'm saying the massively complexity comes in trying to use these new features.

KirinDave 10y ago

I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs. Right now, everyone who's supported both mobile and web APIs (or cared about bandwidth constraint) can tell you how frustrating it is that well factored restful (or rest-ish) APIs are often the casualty of accepting the realities in mobile client support. You end up increasingly collapsing requests into one Special Bigger Request because One Special Bigger Request almost always has better performance on bandwidth-constrained clients than the same performance elsewhere. And this is especially frustrating because often times the client can't tell us exactly what they need in the initial request. The best we often can do is stash an etags header in the request and try and get very fancy there. We end up with smarter endpoints which require tons more programmer maintenance, and move us away from the world of autogenerated and automatically audited endpoints. HTTP/2 w/ Push offers us a way to split the difference. While individual endpoints can be served very quickly, we can have our APIs recognize (via etags, probabilistic inference, previous negotiation, etc) that more data is about to be requested and push it immediately. This means we can keep our well-factored, simple API designs that we developed 10 years ago without sacrificing performance to the bandwidth-constrained. It means that we can further lean on the abstraction Service Worker gives us in web clients to just naively poll in client code and trust in clientside caching to make this efficient (with the fallback being the same network call we would have always made). It's why I'm absolutely infuriated with so many languages for balking at supporting HTTP/2 as part of their stack (more often than not, on the grounds that SSL + ALPN seems tedious to implement).

renke1 10y ago
I agree with everything you said. One thing though, I think "One Special Bigger Request" still makes sense in a lot of situation where you have some kind of "transaction" going on. I often encountered code that calls multiple HTTP endpoints and a failure in one of those requests would actually lead to inconsistent data in the backend. This code is pretty common because many developers assume that requests never fail.
- KirinDave 10y ago
  Transactional mutations have to have a commit phase. I agree.

tabeth 10y ago

Can someone recommend an up-to-date book/guide on HTTP(2)? I'm thinking this may do: https://http2.github.io/ https://http2.github.io/, but I'm not sure if that's the best guide. Much of the jargon in the comments is unknown to me. The article in the OP is a good start.

shurcooL 10y ago
I've learned most things about HTTP/2 from talks given by Brad Fitzpatrick. Go's HTTP/2 support in standard library was largely implemented by him.

spankalee 10y ago

For those interested in HTTP/2 Push, check out Eric Bidelman's Push Manifest format[1], which is a JSON format describing the dependencies to push for any request URL. You can generate the manifest by hand or with tools, and then there are servers that can read the manifest and push the right resources.[2] In Polymer we're most of the way done with support for automatically generating push manifests from a dependency analysis of your project[3] and have push manifest support in our dev server and soon a small production server, so you can `polymer deploy` and get a push-enabled site. [1]: https://github.com/GoogleChrome/http2-push-manifest https://github.com/GoogleChrome/http2-push-manifest [2]: https://github.com/GoogleChrome/http2push-gae https://github.com/GoogleChrome/http2push-gae [3]: https://github.com/Polymer/polymer-build/pull/172 https://github.com/Polymer/polymer-build/pull/172

pcollins123 10y ago
This is really interesting thanks. Doesn't this lead to the most highly used static assets being pushed for every subsequent request? Isn't that wasteful? I use varnish cache extensively and am considering writing a probabilistic server push module. It could keep track of subsequent requests and push the next set of assets. This is more of a server module approach rather than client side. Any thoughts on that?

ElijahLynn 10y ago

Worth watching: https://www.youtube.com/watch?v=CkFEoZwWbGQ https://www.youtube.com/watch?v=CkFEoZwWbGQ (HTTP/2: What no one is telling you by Hooman Beheshti @ Fastly) tldr; H2 can be slower than H1.1 under degraded network connections. e.g. mobile connections with high packet loss.

treve 10y ago

It's here, but current server-side implementations are super weak. rel="preload" is a hack. Only the few languages that have a native HTTP 2 push api are really here.