We have to stop insisting that software updates, etc. need to be distributed over HTTPS. Let me tell you why this is not an ideal way of going about it.

Sometimes a seemingly simple and straightforward function hides a surprising performance profile.

This blog post shows how to combine a few tools available with Elixir, OTP, and related ecosystem in order to understand and improve the memory footprint of an HTTP call.

Caddy has been around for a while, so this is a major release for the project. Hard to believe this is true today (emphasis added)

Still the only web server to use TLS automatically and by default.

Caddy 2’s new architecture was inspired by 5 years of experience with Caddy 1 and took 14 months to design. There’s a lot here, so we probably need to get the team on The Changelog or Go Time to discuss in depth.

I love internet history articles like this one from Cloudflare:

On the 11th of January 1982 twenty-two computer scientists met to discuss an issue with ‘computer mail’ (now known as email). Attendees included the guy who would create Sun Microsystems, the guy who made Zork, the NTP guy, and the guy who convinced the government to pay for Unix. The problem was simple: there were 455 hosts on the ARPANET and the situation was getting out of control.

I know the Go community isn’t one for frameworks, but as a long time framework user myself, I’ve never quite understood the resistance. Fiber doesn’t hide the ball. It comes right out and says “this is a web framework written in Go”. Here’s the philosophy behind that:

New gophers that make the switch from Node.js to Go are dealing with a learning curve before they can start building their web applications or microservices. Fiber, as a web framework, was created with the idea of minimalism and follow UNIX way, so that new gophers can quickly enter the world of Go with a warm and trusted welcome.

Fiber is inspired by Express, the most popular web framework on the Internet. We combined the ease of Express and raw performance of Go. If you have ever implemented a web application on Node.js (using Express or similar), then many methods and principles will seem very common to you.

Deno (the new JS/TS runtime from Node creator Ryan Dahl) is nearing its 1.0 release, so it’s getting a first (or second) look by many curious devs out there.

HTTP/3 is the next protocol for network communication across the Web, which is meant to partially replace HTTP/1 and HTTP/2. One month before the next QUIC Working Group meeting, to be held in Zurich next February, it may be useful to recap what HTTP/3 promises and what its current client/server support looks like.

It’s been awhile since we discussed QUIC and HTTP/3 with curl’s Daniel Stenberg. A lot has happened since then, and this InfoQ article will do a good job of catching you up. Browser support is still limited, but things are coming along nicely.

localdots combines Caddy and smallstep/certificates with automated configuration and hot reload.

• Generates SSL/TLS certificates automatically
• Reloads Caddy automatically with every change

An activity diagram to describe the resolution of HTTP response status codes, given various headers, implemented via semantical callbacks.

This would look cool hanging on your wall (or the wall of a special web developer in your life 😉).

A fun, quick dive into Facebook’s tracking pixel and how it does its thing:

I think it’s fun to see how cookies / tracking pixels are used to track you in practice, even if it’s kinda creepy! I sort of knew how this worked before but I’d never actually looked at the cookies on a tracking pixel myself or what kind of information it was sending in its query parameters exactly.

Creepy, indeed. Our browsers are the last line of defense against such creepiness. Choose yours wisely.

This is, effectively, an HTTP API on top of MaxMind’s free geoip-lite database. If you’re doing anything serious with ip-to-geolocation, I’d advise self-hosting the database, but for small side projects and the like, this is an easy way to get up and rolling.

Eve Martin:

Sometimes we need information from our servers instantaneously. For this sort of use case our usual AJAX request/response doesn’t cut it. Instead, we need a push-based method like WebSockets, Long Polling, Server-Sent Events (SSE) and - more recently - HTTP2 push. In this article, we compare two methods for implementing realtime - WebSockets and Server-Sent Events, with information on which to use and when.

This is a nice, reasoned comparison of the two technologies: advantages, stumbling blocks, open source resources, etc.

Around the advent of GraphQL, I found myself asking its proponents if HTTP/2 solves any of the same performance problems. Most of the answers were along the lines of, “it might, but that hasn’t been realized yet.” Well, Vulcain is here to realize it.

Over the years, several formats have been created to fix performance bottlenecks impacting web APIs: over fetching, under fetching, the n+1 problem…

Current solutions for these problems (GraphQL, JSON:API’s embedded resources and sparse fieldsets, …) are smart network hacks for HTTP/1. But these hacks come with (too) many drawbacks when it comes to HTTP cache, logs and even security.

Fortunately, thanks to the new features introduced in HTTP/2, it’s now possible to create true REST APIs fixing these problems with ease and class! Here comes Vulcain!

See also their comparison between Vulcain, GraphQL, and API formats.

Monolith saves HTML pages as a single file (embedding all assets such as CSS, JS, and images) so…

You can finally replace that gazillion of open tabs with a gazillion of .html files stored somewhere on your precious little drive.

There are other spider management systems out there, but most of them limit you to Python because Scrapyd. Crawlab has no such dependency, so you can use whichever language/framework you’d like.

(This looks like a pain to operate, but docker-compose helps quite a bit in that arena.)

It’s completely modular, and built directly for async/await. Whether it’s a quick script, or a cross-platform SDK, Surf will make it work.

I bet you can learn a lot about Bash scripting from this project. Comes with a caps locked disclaimer:

DO NOT USE THIS IN ANY PUBLIC FACING SERVER. THIS IS NOT SECURE. FOR EDUCATIONAL USE ONLY.

The core idea of this project is to do more with less. PipeHub being a programmable proxy allow users to extend and customize it as needed. Features found in other servers can be added with Go packages.

Not ready for production, but interesting nonetheless. Not sure if PipeHub is something that might serve you well? Here’s some pretty good advice to help you decide:

If your requirement is covered by built-in features present on other servers like Nginx and Caddy, you’re better of with then. PipeHub shines when you need to add logic that traverses the responsibility of multiple servers…

As of March 14, 2019, Google Image Charts API is no longer in service. That’s a shame, because it was a convenient way to easily generate a chart image from a URL. The good news is an open source replacement is ready for service!

It’s also a wrapper script around several security tools such as Mozilla Observatory and Nmap NSE.

Mint is a new low-level HTTP client that aims to provide a small and functional core that others can build on top. Mint is connection based: each connection is a single struct with an associated socket belonging to the process that started the connection.

This looks like an excellent base layer for the Elixir community to build HTTP clients upon. Take note: The core Elixir team is so good at laying foundations like this. Plug, for example, is a near-perfect base layer for HTTP servers.

HTTP View is a desktop tool for supercharged HTTP(S) debugging. It gives you one-click setup for HTTP and HTTPS interception, and all the tools you need to quickly explore, examine and understand the HTTP your code (or anybody else’s) is sending.

Open source, cross-platform, and easy on the eyes. This is definitely worth a look.

Brad Fitzpatrick is going back to the drawing board on Go’s net/http Client and Transport. The linked repo is in its “problem collection” phase, but it’s worth following (or getting involved) now before the actual solution begins to take shape. What’s wrong with the status quo? The list of problems is extensive (and growing).

We recently talked with Daniel Stenberg about HTTP/2 and QUIC, so this news comes with little surprise looking back on that conversation with hindsight.

The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham.

On November 7, 2018 Dmitri of Litespeed announced that they and Facebook had successfully done the first interop ever between two HTTP/3 implementations. Mike Bihop’s follow-up presentation in the HTTPbis session on the topic can be seen here. The consensus in the end of that meeting said the new name is HTTP/3!

Handling dynamic virtual hosts, load balancing, proxying web sockets and SSL encryption should be easy and robust.

I agree! With built-in support for clustering, HTTP/2, LetsEncrypt, and Docker, this is worth a look. 👀