DEV Community: Michael Driscoll

Safe HTTP/3 Experimentation With Caddy

Michael Driscoll — Mon, 25 Apr 2022 01:22:29 +0000

The Bleeding Edge Problem

I'm writing QUIC documentation and thought it would be great to have the site available as HTTP/3 (which runs on top of QUIC). This is a relatively new protocol, so I ran into some familiar problems:

Tooling: The webserver that I'm using (apache) doesn't offer HTTP/3 support, and has no current plans to
Uptime: The page in question is relatively popular, and I don't want to risk it going down while I set this up

The QUIC Possibility

Luckily the details of the QUIC transport protocol give us some flexibility here:

QUIC uses a different underlying protocol (UDP vs TCP), so I can leave apache on TCP port 443 and put up a reverse proxy on the UDP port
All HTTP/3-capable browsers will try QUIC and, if they get a connection error, will fall back to TCP (and the unmodified apache setup)

The Solution

The fix is a simple Caddy reverse proxy. It's running in a docker container to let me "split the bindings": Caddy wants to bind both TCP and UDP ports but I can only give it the UDP port. Containerizing gives me the flexibility of letting it bind both in its container, but only exposing the UDP port to the world.

Details

The Caddy installation looks like this. You'll want to tweak a few lines, indicated with "youruser" or "yoursite" placeholders:

setup:

### change as appropriate for your OS
sudo snap install docker

mkdir ~/caddy/
mkdir ~/caddy/caddy_data
mkdir ~/caddy/caddy_config

~/caddy/docker-compose.yaml:

version: "3.7"

services:
  caddy:
    container_name: caddy
    hostname: caddy
    image: caddy:2.4.6
    restart: unless-stopped
    ports:
      - "443:443/udp"
    volumes:
      - /home/youruser/caddy/Caddyfile:/etc/caddy/Caddyfile
      - /path/to/yoursite/fullchain.pem:/caddy.crt
      - /path/to/yoursite/privkey.pem:/caddy.key
      - /home/youruser/caddy/caddy_data:/data
      - /home/youruser/caddy/caddy_config:/config
    extra_hosts:
      - "host-gateway:172.17.0.1"

volumes:
  caddy_data:
    external: true
  caddy_config:

~/caddy/Caddyfile:

{
    auto_https off
    servers {
        protocol {
            experimental_http3
        }
    }
}

yoursite.com {
    tls /caddy.crt /caddy.key
    reverse_proxy * https://host-gateway {
        transport http {
            tls_insecure_skip_verify
        }
    }
}

startup:

cd ~/caddy
sudo docker-compose up -d
### tail the logs with `sudo docker logs -f caddy`

Advertising HTTP/3

The above sets up a reverse proxy that serves HTTP/3 on UDP port 443, but nothing will try it until you advertise it on your "real" HTTP server. Fortunately this minor config was the only change needed on the production server:

In my VirtualHost apache config for the site:

Header set alt-svc "h3=\":443\"; ma=3600, h3-29=\":443\"; ma=3600

This advertises an HTTP/3 service (both "standard" and "draft 29" versions of the protocol) with the "Alt-Svc:" header. You'll need to bounce apache for this to take effect.

Cert Rotation

One last thing is needed to handle cert rotation. The above solution copies your site certificate and key into the Caddy container, but if you're using LetsEncrypt that cert is only good for three months and is likely being rotated monthly. I run the following in cron to ensure the container is always capturing a relatively fresh certificate:

### bounce the reverse proxy every month
39 0 25 * * cd /home/youruser/caddy && /path/to/docker-compose down && /path/to/docker-compose up -d

cover image by Stephen Cleary CC 2.0

Roughing It with Lisp

Michael Driscoll — Sun, 15 Jan 2017 04:34:09 +0000

Like many software devs, I have a wispy, tenuous, almost nonexistent relationship with Lisp. In high school I'd dabbled with emacs, in college I had one lambda-loving friend that I mostly ignored, and once I was in the workforce I'd always put "learn some Lisp" on my todo list, usually near the bottom.

It wasn't until a few weeks ago, when reading Eric Normand's article "The Idea of Lisp" that I finally got the itch. But how should I go about it? The article describes the original LISP as a set of five primitives of which the runtime is constructed, like Euclidean geometry which is based on five irreducible axioms. I had never actually written a language interpreter, and I thought it would be fun to read the original McCarthy paper and see if I could implement the language as described. Not having an IBM 704 handy I was going to write it in C, in as little code as ~~possible~~ reasonable, and leaning as heavily as I could on the primitives given. I wasn't going to cheat and look at other Lisp resources, though I did take a peek at the Wikipedia article on S-Expressions as the visual layout in the original paper wasn't as clear to me. In short, I wanted to pretend it was April 1960 and I'd just gotten the latest copy of CACM, like some modern-day hiker going out into the woods to pretend that they don't have GPS handy.

There are a few things that you work out as you implement the language in this paper. For one, most of the code in the paper is in M-expressions, which are not idiomatic to an Algol-ist like me, and apparently never implemented in software. Once you're over that hurdle and you're transcoding M-expressions into your language of choice, you'll notice that the function definitions in the paper are sometimes missing a termination condition, or the behavior in some area is unspecified, or the parentheses in a definition are not balanced (ironic in a paper about Lisp). After you've made some fixes and specified the unspecified, you'll also find that there's an error in the definition of eval. I spent half a day working out the latter, only to discover later that the error and the fix are well known (McCarthy hints at it in a 1995 update, and Paul Graham spells it out in The Roots of Lisp).

The result is, well, a crude Lisp implementation, with the features described in the paper including mark-and-sweep GC, plus some 2-function math. It's remarkable in that it can parse S-expressions and perform recursive functions in a few hundred lines of C, but it's not a language you'd want to live in. The first thing you'd want to do with it is make the obvious additions to make it more useful (I'd already started by adding a defun that puts the necessary lambda and label references in a global args scope). You can really tell that the original paper was an attempt to capture a moving object, that it was a snapshot in time, presumably not long after recursive functions were shown to work but before anyone had done useful work with them.

It's incredible that this existed in the fifties, a full decade before my universe is usually thought to have begun. The original Lisp is like a John Harrison clock in that you can't imagine how it was conceived, how it was crafted, or how everything fits so well together. Thanks for the article Eric, you've shown me a gem.

cover image by David Fielding (aviatordave@flickr) CC BY-NC-ND 2.0

Hi, I'm Michael Driscoll

Michael Driscoll — Sun, 15 Jan 2017 02:51:04 +0000

I have been coding since 1995.

You can find me on GitHub as syncsynchalt

I live in Parker, Colorado (near Denver).

I have worked for many companies, all of which I started, and am currently retired and bumming around Intel in my free time.

My coding progression was C, Perl, C++, Java, Groovy, and eventually everything.

I am currently learning more about calligraphy.

Nice to meet you.