typo...

rename `mime MIME EXT' to `map MIME to-ext EXT' With the newish automatic string concatenation, options like `mime' that accepts two strings as parameter start to become ambiguous: which strings gets concatenated? Instead of trying to document in the manpage which argument(s) is subject to string concatenation, do the concat always and introduce a separator. In the case of mime, `to-ext' now acts as a separator to distinguish. While there, also use a new keyword because it sounds better. It's dead-easy to upgrade to the new configuration, possibly with some sed magic, but for the moment the old `mime' form is preserved: (with a warning!) Will be dropped in the next release.

use bsearch to match the keywords not that it's a bottleneck, but it's fancier this way.

don't expand macros inside the quotes Now that we have this auto concat string thingy, macros can simply expand to standalone strings in place, as single words. Forgot to point it out in previous commits, but now we can cert = "/etc/keys" server "foo" { cert $cert "/foo.crt" ... }

align

[config] concat two or more strings next to each others

don't require the strict order macro > options > servers

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 }

trailing whitespaces

give a name to the anonymous union

move lineno/colno into the token struct

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

add `param' keyword

refactor fastcgi block

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