introduce IMSG_LOG_REQUEST

move version number to configure script

move parse_portno to gmid.c it's used only to parse the -p flag. While there add check_port_num to check the range for the port.

style(9)-ify

gracefully shut down fastcgi backends we need to delete the events associated with the backends, otherwise the server process won't ever quit. Here, we add a pending counter to every backend and shut down immediately if they aren't handling any client; otherwise we try to close them as soon as possible (i.e. when they close the connection to the last connected client.)

allow to define macros in the config file Macros can be defined at the top of the configuration file: dir = "/var/gemini" cert = "/etc/keys" and re-used later, for example server "foo" { root "$dir/foo" # -> /var/gemini/foo cert "$cert/foo.pem" # -> /etc/keys/foo.pem }

define GMID_STRING and reuse-it GMID_VERSION follows the CGI/FastCGI style, i.e. project_name/version. Define GMID_STRING with a more "human" variant "project_name version", and reuse that in the --help and --version codepath.

drop the dependency on lex by implementing yylex by ourselves The actual implementation is based off doas' parse.y. This gave us various benefits, like cleaner code, \ to break long lines, better handling of quotes etc...

allow sending fd to log on to the logger process the logger process now can receive a file descriptor to write logs to. At the moment the logic is simple, if it receives a file it logs there, otherwise it logs to syslog. This will allow to log on custom log files.

more params from and send a custom list

define and use GMID_VERSION

use the correct document root pass the correct loc_off to the executor, so the various variables that depends on the matched location (like DOCUMENT_ROOT) are computed correctly.

drop forward declaration of struct client it's been since the switch to libevent that is no longer needed.

fastcgi: a first implementation Not production-ready yet, but it's a start. This adds a third ``backend'' for gmid: until now there it served local files or CGI scripts, now FastCGI applications too. FastCGI is meant to be an improvement over CGI: instead of exec'ing a script for every request, it allows to open a single connection to an ``application'' and send the requests/receive the responses over that socket using a simple binary protocol. At the moment gmid supports three different methods of opening a fastcgi connection: - local unix sockets, with: fastcgi "/path/to/sock" - network sockets, with: fastcgi tcp "host" [port] port defaults to 9000 and can be either a string or a number - subprocess, with: fastcgi spawn "/path/to/program" the fastcgi protocol is done over the executed program stdin of these, the last is only for testing and may be removed in the future. P.S.: the fastcgi rule is per-location of course :)

added missing prototype