BUFSIZ is variable, we need *exactly* 1024 Using BUFSIZ in sbuf is not OK. It's variable, and in various places we assume that sbuf is 1024 (like handle_cgi_reply). We could patch those, but we aren't sure BUFSIZ is >= 1024! Let's keep the hardcoded number. (found by debugging on arch on amd64, where BUFSIZ is bigger)

don't mmap Before we mmap(2) file for reading, and use a buffer to handle CGI scripts. Turns out, for sequential access over the whole mmap isn't better than our loop on read. This has also the additional advantage that we can use handle_cgi (now handle_copy) for both files and CGI, which is pretty cool. This also fixes a nasty bug where we could hang a connection forever, because we scheduled the wrong type of event (read on POLLOUT and write on POLLIN, it's the other way around!)

add `require client ca' rule to require certs signed by a CA

define config_path as global variable

rewrite main loop using libevent

define TLS_CLIENT_NOT_BEFORE/NOT_AFTER in CGI scripts

[cgi] split the query in words if needed and add them to the argv

improve logs management

added prefork option

add the ``entrypoint'' option

added ``block return'' and ``strip'' options

reload configuration on SIGHUP

refactor executor_main now it's symmetrical to listener_main().

refactoring startup logic

revert commit 346f28eeaa205d268d1e63c7ffd86cf041f6d1e6 keep mark_nonblock in utils.c, as otherwise the build for the regress suite will fail (mark_nonblock needs fatal which is in gmid.c, and we can't link gmid.o with the regress suite...)