i.e. allow client_by_id to fail and return NULL. Initially I thought it was a good idea to shut down a server process if we receive an invalid client id as reply from one of our requests to the executor process. This turned out not to be correct since a client can (read: will) disconnect in the delay beteewn we acknowledge their request and the cgi script execution. The fastcgi and proxy handler already handled this situation, so they're unaffected. This allows an attacker to make gmid unresponsible by just making enough requests until they hit the right timing.

The libevent error value is much more interesting! see github issue #13

properly release everything when during client_close if the request was managed by a proxy.

libevent2 can still somehowe call client_read even in code paths that never enable reading from the evbuffer. Can't reproduce on the libevent in base on OpenBSD. It's a bit ugly, but it's a small workaround for something that otherwise *always* make gmid crash when linked against libevent2. (client_read works under the assumption that c->host != NULL, matched_proxy crashes otherwise.)

refactor the code that calls validate_against_ca into an helper function to reuse it in both apply_require_ca and (optionally) in apply_reverse_proxy.

as a side effect the order of the content of a server block is relaxed: options, location or proxy blocks can be put in any order.

it doesn't make any sense to keep the proxying info per-location: proxying only one per-vhost. It can't work differently, it doesn't make sense anyway.

Add to gmid the ability to forwad a request to another gemini server and thus acting like a reverse proxy. The current syntax for the config file is server "example.com" { ... proxy relay-to host:port } Further options (like the use of custom certificates) are planned. cf. github issue #7