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