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
It's been there for a long time, and it's frankly annoying to pretend
to use parameters. Most of the time, they're there to satisfy an
interface and nothings more.
FastCGI is designed to multiplex requests over a single connection, so
ideally the server can open only one connection per worker to the
FastCGI application and that's that.
Doing this kind of multiplexing makes the code harder to follow and
easier to break/leak etc on the gmid side however. OpenBSD' httpd
seems to open one connection per client, so why can't we too?
One connection per request is still way better (lighter) than using
CGI, and we can avoid all the pitfalls of the multiplexing (keeping
track of "live ids", properly shut down etc...)
We can't use normal pipe(2)s with libevent in some cases. Switch to
socketpair(2), which doesn't have the same problem.
This has the drawback that it doesn't prevent the CGI script from
reading stdout, for instance. (sockets are two-way, pipes only one-way)
OpenBSD accept it, but FreeBSD disallows it. PF_UNSPEC (or 0) should
be used instead. The FastCGI bit in the regress suite still doesn't
work on FreeBSD, but at least now it starts.
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.
Omar Polo