we need to delete the events associated with the backends, otherwise
the server process won't ever quit.
Here, we add a pending counter to every backend and shut down
immediately if they aren't handling any client; otherwise we try to
close them as soon as possible (i.e. when they close the connection to
the last connected client.)
quoting strncpy(3)
strncpy() only NUL terminates the destination string when the
length of the source string is less than the length parameter.
strlcpy is more intuitive.
this is another warning gcc 8 found that clang didn't.
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.
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).
Omar Polo