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 :)
log.o is linked to some regress/ stuff. Calling from there a vhost_*
function means that we should link the regress/stuff to server.o too
(and that would pull in other stuff...). Moving the call is easier,
and also probably better.
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.
accept4(2) isn't part of any standard (even though it'll be part in
the future) and raises warnings on some linux distro. Moreover, we
don't have thread that may fork at any time, so doing a mark_nonblock
after isn't a big deal.
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!)
the old server processes would stick around waiting on the signals
events. While there, also drop the `struct server_events' and define
events as globals.
reported by devel at datenbrei dot de. The first location would
overwrite the default value for a server, triggering the "`foo' rule
specified more than once" error. This also needed a small tweak on
how we match locations to avoid breaking other tests.
it's faster (statistically speaking) to first compute if the option is
set and then fnmatch than the inverse. This way we can avoid
unnecessary fnmatch.
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...)
Now that I got rid of the enum+switch, adding more state is easier.
Before, we used an hack to remember if we had read the CGI reply or
not (c->code = -1).
This introduces a new state, handle_cgi_reply that reads the CGI
script reply, logs it, and only then switches to handle_cgi.
handle_cgi itself is cleaner, now it only reads into c->sbuf and send
what it had red.
We even get, almost for free, the 42 error. If read exists with -1 or
0 from in handle_cgi_reply, we return a proper error to the client.
We can extend this further in the future and also try to validate the
CGI reply (for now we're only looking for a \n).
So we don't re-enter the handle_handsahke and re-do the loop on
fnmatch etc. This way, once we're successfully past the handshake,
we'll re-enter no handle_open_conn.
instead of having a flag to discern between two different behaviours
in S_SENDING, split that state into S_SENDING_FILE and S_SENDING_CGI
(this will also make it easier in the future to add other sending
states). While there, also get rid of `goodbye' and make start_reply
advance the state machine by itself.
make sure redirect starts with /. This also requires a tweak in
check_path, in the case we go open_file -> send_dir -> open_file ->
check-path and the path starts with a slash.
the new logging code was crashing if the client didn't support SNI or
if required an unknown vhost: this because we short-circuit in
handle_handshake to an error, so c->iri isn't populated yet (we don't
even read the request).
fixes#1
was probably added to distinguish between AF_INET and AF_INET6, to use
different functions for logging. But it wasn't really used, and now
we use getnameinfo anyway.
err/warn is not available on some systems (unfortunately!) and in any
case don't play well with our daemon mode (that closes std{in,out,err}).
Use our fatal that is daemon-aware.
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.
Omar Polo