HTTP/2 is not the future, it’s the present
blog.eleven-labs.com
blog.eleven-labs.com
[1] RFC7540 - https://tools.ietf.org/html/rfc7540
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.
Even if the government could brute force or fingerprint one of your TLS sessions, they can't do it for everyone for every site.
Just because Amazon wasn't broken doesn't mean we can't improve it.
Also your comment about a think tank coming up with this idea is an odd insult, given how broadly you can empirically see people support this.
Is this based on some odd notion of ClientAuth?
This is a great opportunity to get people to use TLS across the board. The carrot is HTTP/2.
What's more unique about HTTPS traffic than HTTP traffic?
Citation? We've learned what has always thought to have been true: Encryption works very well and intel collectors need to resort to attacking other aspects. TLS has had its share of flaws but it's still very much a "big thing" to defeat.
https://www.wordfence.com/blog/2017/01/chrome-56-ssl-https-w...
https://blog.mozilla.org/security/2015/04/30/deprecating-non...
http://stackoverflow.com/questions/32106849/getcurrentpositi...
https://konklone.com/post/were-deprecating-http-and-its-goin...
http://forums.whirlpool.net.au/archive/2598616
Just some random places to start to see why the major web browsers are not going to spend any time on non-encrypted protocols. A lot of devs need to help themselves and move to encrypted to connections before they are forced at browser-point.
With TLS, not only is it less common for the connection to be intercepted, but also a MITM proxy which doesn't understand HTTP/2 won't negotiate it with either end, transparently falling back to HTTP/1.1. And firewalls will only see the outer TLS protocol.
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).
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.
GraphQL seems to be a great candidate for bridging this gap. I recommend using graphql to allow clients can use to make "One Special Bigger Request" which then gets split into multiple requests on the backend.
If you want network-level caching, you want multiple atomic resource requests. HTTP2 enables this.
Very true. The talk around around server push has suffered a bit from tunnel-vision, only taking browser-media delivery into account, making it look like a browser feature only.
HTTP2 + server push can actually make GraphQL less relevant, same way that there hasn't been talk around supporting websockets in it (it just doesn't look necessary anymore).
But for all this to happen, server push needs to become cacheable. And I really hope that the cache digests rfc takes off and gets more implementations.
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!
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
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.
"HTTP/0.9" is used to describe the implementations of "HTTP/1.0" before it was -- for lack of a better word -- 'ratified'.
If you, or anyone, has more information or analysis of pre-HTTP/1.0 protocol implementations (client or server), I would be very interested in reading it.
Also, if there is a public, pre-HTTP/1.0 HTTP server available on the internet, I would very much like to check it out.
Thanks.
Edit: Alternatively, if it's possible to run an pre-HTTP/1.0 server (or client), that would be phenomenal. It only occurred to me after making the comment, however I highly doubt that it would be a simple process to get one running. I suspect that I wouldn't be able to spin a Docker container with some ancient version of Apache (I assume due to changes in the Linux environment, shared libraries, changes to gcc, etc.), but possibly, a VM running an equally-ancient version of Red Hat (pre-EL) would do the trick.
It's a little more sophisticated than GET /, as you can also specify a full URL.
> Also, if there is a public, pre-HTTP/1.0 HTTP server available on the internet
Most HTTP/1.0+ web servers still support HTTP/0.9. I don't know of any 0.9-only servers though, but there's probably some.
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.
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).
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.
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
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?
Much of the jargon in the comments is unknown to me. The article in the OP is a good start.
AFAIK, the Assets Pipeline in Rails is not designed for HTTP2 and I think that there are no immediate plans to implement it.
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.
That sounds like a bad idea in the long term... ;)
>The “Server Push” feature defined in the HTTP/2 RFC is not supported in this release. Future releases of NGINX Plus might include it.
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/
[2]: https://www.chromium.org/spdy/link-headers-and-server-hint
tldr; H2 can be slower than H1.1 under degraded network connections. e.g. mobile connections with high packet loss.
[1] https://news.ycombinator.com/item?id=14082636 [2] https://shouldipush.com [3] https://youtu.be/GjWD1pOkxUk?t=1534
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.
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-ser... [2]: https://blog.cloudflare.com/announcing-support-for-http-2-se...
It only gets properly messy once you look at the real TCP state transitions: https://www.cl.cam.ac.uk/~pes20/Netsem/poster.pdf
[1]: https://caddyserver.com/blog/caddy-0_9-released#easy-self-si...
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.
The problem here is you are thinking about just yourself. Yes, it's hard to do learn all these things. It was especially hard back then because the the sources to learn were pretty crappy and taught a lot of bad things. That's part of the reason we have the 'exploit a day' internet we suffer from now.
If new web developers have to learn both protocol security and code development, it will probably mean less developers. Which is great for the ones that take the time to learn, they'll get paid more. It also is probably better for the customer, hopefully it will mean they are less likely to get served virus_porn_encrypt-your-computer.exe from your half baked website.
Tomcat and apache are still massively deployed. If you moved to nginx years ago, remember than it's still a new toy for a huge number of people. So caddy...
The only unfortunate thing is, that RHEL7/CentOS7 have OpenSSL 1.0.1 and mod_http2 requires OpenSSL 1.0.2. Thus no http2 there.
If you can create one, presumably for your internal network, with no public facing parts, how exactly does letsencrypt "screw you"? You can create and distribute self-signed certificates today, just like you could the past 20 years.
Browsers will still support HTTP in a decade (current low-powered network hardware and the like will still be around and need to work).
And of course down the road you will have to figure out subdomains, cross domain requests, media streaming, embedding external unsecure content, debugging on mobile devices, etc.
And of course this will work only if you are on a private server, cause on the simplest hosting you won't have this.
You lost touch with the quantity of knowledge you accumulated over the years.
There is an easy answer to that.
DON'T
Most browsers block it at this point, and rightfully so. A single unencrypted include can be used to inject malicious content on a web page. Lots of people use internet over untrusted connections (open wireless) or partially trusted connections (ISPs injecting content).
>You lost touch with the quantity of knowledge you accumulated over the years.
Therefore we must lobby that our skill set is protected by law and that protocols and best practices are not allowed to change! Uh? Sorry man, you are going to have to evolve as the internet changes. Well, you don't have to, but when all your devices are encrypted and asking for a few bit coins to unlock, you will have been warned that it was going to happen.
> DON'T
Easy to say when your business is no tied to advertisers on which you have zero leverage.
> Therefore we must lobby that our skill set is protected by law and that protocols and best practices are not allowed to change!
Making TLS optional on HTTP2 would have not taken anything from you. You are just here in your ivory tower looking down on people that are clearly not as pure as your are.
Well sorry, but down there, among the humans, you have PHP dev that are using EasyPHP, people that don't know the command line, people using mixed content and have no control over it, people that can't spend hours to continuously learn new things every week, people that don't have private servers and so on.
And you know what ? I'm not even among them. I run my service on private servers with https. I use docker, letsencrypt and react or whatever is useful to me.
But giving trainings and having friends running side business, I know that it's not the only reality in IT.
So basically, right now, HTTP2 is just built to be hard for a huge part of the dev population, with no good reasons.
Then it is time for your business to die. Sorry about your luck.
>Making TLS optional on HTTP2 would have not taken anything from you.
It would have reduced my security in the future when developers used it inappropriately.
>Well sorry, but down there, among the humans, you have PHP dev that are using EasyPHP, people that don't know the command line, people using mixed content and have no control over it, people that can't spend hours to continuously learn new things every week, people that don't have private servers and so on.
Then evolutionary forces far beyond them are going to push them to extinction. Adapt or die as they say. Your friends running side businesses need to realize they are on the public internet subject to grand forces far beyond their imagination. Malicious governments watching recording everything they can on people. ISPs injecting ads into customer data streams and selling browsing habits to third parties. Blackhats compromising machines to steal, or to spread trojans to client computers. Those things are real threats that the 'lowly humans' have to know about if they want to do business on the Internet and not be totally compromised. The fact that bad people exist just raises the cost of doing business.
Cry me a river. Devs want to pump out as much code as possible without thinking about the security considerations. Who cares about the end user that's going to get pwned, right?
HTTP is being phased out. HTTPS certs are available for free. Companies can use self generated certs if needed. The days of exchanging unencrypted text over the internet and blindly expecting some evil or ignorant 3rd party not to tamper with it is long gone.
It will suck to have to resort to essentially MITM tactics on my developer workstation in order to decrypt local traffic. Yes, there are tools like Fiddler that can do this, but eventually it may be impossible to MITM traffic the way Fiddler does. That will make it more difficult to debug applications. There are also platforms like Pivotal Cloud Foundry that rely on being able to inject headers into HTTP messages as the messages traverse the platform (e.g., to support throttling); this will become more difficult if that traffic has to be encrypted.
HTTP/2 with forced TLS is, in effect, a binary protocol. Right now, developers all over the world enjoy the plain-text and hackable nature of HTTP 1.x.
For example, Google is making it as difficult as possible to install certificate authorities in Android. Root certificates are encrypted as if they are client certificates, requiring the user to set up PIN or password protection on their lock screens. Removing this protection immediately disables the installed user certificates.
Google has changed the Android 7 API so that by default the user certificate store is not used to validate the validity of certificates (only the system store is used). Apps need to opt in to still support user certificates.
Of course this is all done to prevent malicious actors from performing MitM attacks on users. Still, I would not be surprised if Android P removes the user certificate store all together.
So I've noticed exactly 0 difference in my workflow between HTTP 1 and HTTP 2.
sorry, I must have misread "socat" as "netcat". Since socat's HTTP integration is an HTTP proxy on port 8080 it should be transparent due to using "CONNECT" for https.
curl offers --http2 and uses ALPN where available as explained here: https://curl.haxx.se/docs/http2.html
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.