Yep, fd should be the file descriptor, but for lazyness when manually
calling the function sometimes we supply 0 as fd and event. Instead of
fixing the usage, do as other of such functions do in this
circumstances: use c->fd.
it's not technically required, since a couple of lines below we free
whole host struct, and we don't have code that may use
h->{env,aliases} afterwards, but it's nice not to have invalid
pointers around. it may bite in the future.
don't add gmid as organisation when generating the certificate, and
set the version to 3, so it's compatible with java/android clients.
Found by Gnuserland, thanks!
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 :)
With -f, when the main process exits after a fatal() (usually) the
shell prompt is printed before the logger message.
This adds a small poll to wait for the logger process to exit.