tested on openbsd, alpine and void

leftover from when README.md was generated by gmid.1

we still have an hardcoded list, but this implements the API needed to modify the mappings.

cgi.c wasn't really needed; it better to group all the server related functions together, cgi or not. Now gmid.c contains only startup and utility code.

this way, we can sandbox the listener with seccomp (todo) or capsicum (already done) and still have CGI scripts. When we want to exec, we tell the executor what to do, the executor executes the scripts and send the fd backt to the listener.

* gmid.c (main): changed behaviour: daemon off by default (main): changed -c in -C (cert option) (main): changed -k in -K (key option, for consistency with -C) (main): added -c to load a configuration (main): certs, key and doc (-C -K and -d) doesn't have a default value anymore (handle_handshake): add vhosts support

It's correct, while my hacked valid_multibyte_utf8 would allow things that aren't technically UTF8.

Up until now I used a "poor man" approach: the uri parser is barely a parser, it tries to extract the path from the request, with some minor checking, and that's all. This obviously is not RFC3986-compliant. The new RFC3986 (URI) parser should be fully compliant. It may accept some invalid URI, but shouldn't reject or mis-parse valid URI. (in particular, the rule for the path is way more relaxed in this parser than it is in the RFC text). A difference with RFC3986 is that we don't even try to parse the (optional) userinfo part of a URI: following the Gemini spec we treat it as an error. A further caveats is that %2F in the path part of the URI is indistinguishable from a literal '/': this is NOT conforming, but due to the scope and use of gmid, I don't see how treat a %2F sequence in the path (reject the URI?).