remove the fcgi debug code

call getnameinfo() only once per request

copyright years++

implement `listen on' 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.

use fatal() in code used in the daemon

switch to the more usual log.c

rename log.[ch] to logger.[ch]

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

add an implicit fastcgi parameter: GEMINI_SEARCH_STRING 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.

return after FCGI_END_REQUEST 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!

always send custom list of fcgi parameters 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.

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

fmt

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

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