As we are still trying to get the grip with HTTP/2, the world is moving on. Here’s the blog post with some initial details on HTTP/3 and QUIC. Turns out, we moving away from TCP to UDP with encryption.
Here are more details from the CloudFlare blog post.
Let the fear, uncertainty, and doubt begin!
“The Illustrated TLS Connection” is an interactive guide to the TLS connection, explaining every byte with code, comments, annotations, and more. If you ever wanted to know the details of how this works, I can’t think of a better resource to direct you to. And if you find any issues or can suggest a better explanation, there’s a GitHub repository for you to contribute.
“The headers we want” is a very simple, straight to the point blog post on the Fastly blog. Unlike many other more generic articles on the subject, it doesn’t try to explain the meaning of every HTTP header out there, and it doesn’t go into deep theory or the meaning of life, the universe and everything.
Instead it tells you plain and clear which headers should be emitted by your website or web application. And these cover everything from the usual Content-Type and Content-Length, all the way down to the CORS and Server-Timing.
Once the basic functionality of your website or web application is done and out of the way, this blog post comes in handy with the specific best practices to make your site more secure and much faster.
For more on the same subject, have a look at “The headers we don’t want” in the same blog.
Here are some very exciting news from Let’s Encrypt:
We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.
ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.
Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.
Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.
Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.
Here are some very exciting news from the Nginx front lines: HTTP/2 Server Push is now available in the latest and greatest Nginx 1.13.9, which was released yesterday!
Server Push was one of the most exciting features for me in all of the HTTP/2 specification. But I wasn’t quite sure how it will be implemented, and, most importantly, how it can be made easily available to the web developers, who are often few levels removed from the web server configuration. I think Nginx solves the problem quite elegantly.
On the configuration level, “location” directives are often available to the web developers withing the virtual host / server. But for those who can’t use those or don’t want to mess around with the configuration files, an even easier option is available – Link HTTP header.
I’m sure this will soon be widely supported in all the major libraries and frameworks, much like HTTP cookies are. Great times ahead!