our stderr could have been sent to the logger process, so it may be
invalid. Furthermore, in the future we may want to capture also the
stderr of the processes.
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 :)
this fixes a bug introduced with the prefork mechanics: every server
process shared the same socket, and this would cause a race condition
when multiple server processes asked for a script cgi being executed.
This gives each server process its own socket to talk to the executor,
so the race cannot happen.
Include gmid.h as first header in every file, as it then includes
config.h (that defines _GNU_SOURCE for instance).
Fix also a warning about unsigned vs signed const char pointers in
openssl.
FRC3875 says that if the query does not contain any unecnoded "="
characters, we SHOULD treat the query string as a "search-string",
split in on "+" and add every word to the CGI argv.
In launch_cgi it's too late because iri->query is the *decoded* query!
I have in mind some refactoring around how we decode things, so this
is postponed.
Oh my, this is such a stupid mistake. It went undiscovered only
because I always used CGI scripts on the first vhost (and hence the
offset would be 0) and never on the others.
when we switched from one process to two, I introduced a small
optimisation: empty string are not send, so we receive NULL.
Constructing requri we need to make sure that relpath is not null.
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.