one FastCGI connection per client FastCGI is designed to multiplex requests over a single connection, so ideally the server can open only one connection per worker to the FastCGI application and that's that. Doing this kind of multiplexing makes the code harder to follow and easier to break/leak etc on the gmid side however. OpenBSD' httpd seems to open one connection per client, so why can't we too? One connection per request is still way better (lighter) than using CGI, and we can avoid all the pitfalls of the multiplexing (keeping track of "live ids", properly shut down etc...)

allow to run only a subset of the runtime tests with make TESTS='test_1 test_2 ...' regress now it's possible to run only that specified subset of tests. It's really useful during debugging :)

plug a memory leak c->req is set in client_read but never deallocated

fmt

add the upload target to ease publishing the site

[gemini] tweak the contrib page I find it more readable with some empty lines here and there

improve the service file usage instructions Thanks Martin for providing these information :)

add targets to serve the site locally

import the capsule/website

add .cirrus.yml Add a cirrus CI config file that runs the regression suite on linux amd64/aarch64 and on freebsd.

re-add sha script; it's used in the Makefile While there, use it in the tests too

sync changelog

reduced the timeout time for single checks

copy only `len' bytes, not the whole buffer We ended up copying too much data from the fastcgi process.

allow running only specific tests It's now possible to run only a subset of the tests with: ./runtime test1 test2 ...