Listening by default on all the addresses is so bad I don't know why I haven't changed this before. Anyway. Add a `listen on $hostname port $port' syntax to the config file and deprecate the old "port" and "ipv6" global setting. Still try to honour them when no "listen on" directive is used for backward compatibily, but this will go away in the next next version hopefully. At the moment the `listen on' in server context don't filter the host, i.e. one can still reach a host from a address not specified in the corresponding `liste on', this will be added later.

fatal usually appends the error string. Add 'fatalx' that doesn't. Fix callers and move the prototypes to log.h

it’s the QUERY_STRING decoded if it’s a search-string (i.e. not a key-value pair.) It’s useful for scripts to avoid percent-decoding the querystring in the most common case of a query, because in Gemini querystrings key-value paired are not common. Idea from a discussion with Allen Sobot.

this fixes a possible crash if `client_write' closes the connection, because client_close can end up freeing the fastcgi bufferevent while we're looping. We don't support fastcgi multiplexing, so once we get an END_REQUEST there's nothing more to do. Prodded into looking here after a bug report from Allen Sobot, thanks!

The code in fcgi_req to send the custom params set in the config file was placed inside the conditional for `tls_peer_cert_provided`, so the custom parameters would not be sent if a client certificate is not provided.

matches found with % grep -R '=[ ]*{' . | fgrep -v const

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