it doesn't make any sense to keep the proxying info per-location:
proxying only one per-vhost. It can't work differently, it doesn't make
sense anyway.
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
Currently dogfooding this patch at gemini.sgregoratto.me. To test,
run the following command and look for the "OCSP response" header:
openssl s_client -connect "gemini.sgregoratto.me:1965" -status
This adds a barebone dumping of the parsed configuration. It is not
complete, but I'm interested in dumping the full path to `cert' and
`key' in order to write some scripts that can inspect the
configuration, extract the certificates and renew them when expired
automatically.
It's not easy to parse gmid configuration otherwise because the syntax
is flexible and users can use macros. Instead, the idea is to run
gmid and let it dump the configuration once it's been parsed in a
static and predictable format.
Now is possible to parse gmid configuration with, say, awk or perl.
Error and warning messages are prefixed with "error: " and "warning: "
correspondingly to ease integration with automated tooling.
`yywarn' function added. Off-by-one line numbers in warnings are fixed.
Two error messages are reworded to avoid repeating like
"error: error in server directive" or "error: syntax error".
* expand $-macros as string, only the new @-macros get expanded as-is
* rollback changes to characters allowed in bare strings
* optional semicolons in optnl, useful for readable @-macros
This allows to solve the problem with the \n in the grammar (before
two following macro declaration were treated as invalid. This also
brings in a nice `include' keyword.
In the same spite of the last commit, add the missing separators
between strings to avoid the auto-concat pitfalls. `=>' is used to
separate between `env' and `param' arguments, while for `fastcgi' the
keyword `port' is required between the hostname/ip address and the
port (if provided).
Since `env', `param' and `fastcgi' are all new stuff, there's no need
to keep compatibility.
With the newish automatic string concatenation, options like `mime'
that accepts two strings as parameter start to become ambiguous: which
strings gets concatenated? Instead of trying to document in the
manpage which argument(s) is subject to string concatenation, do the
concat always and introduce a separator. In the case of mime,
`to-ext' now acts as a separator to distinguish. While there, also
use a new keyword because it sounds better.
It's dead-easy to upgrade to the new configuration, possibly with some
sed magic, but for the moment the old `mime' form is preserved: (with
a warning!) Will be dropped in the next release.
Now that we have this auto concat string thingy, macros can simply
expand to standalone strings in place, as single words.
Forgot to point it out in previous commits, but now we can
cert = "/etc/keys"
server "foo" {
cert $cert "/foo.crt"
...
}
Macros can be defined at the top of the configuration file:
dir = "/var/gemini"
cert = "/etc/keys"
and re-used later, for example
server "foo" {
root "$dir/foo" # -> /var/gemini/foo
cert "$cert/foo.pem" # -> /etc/keys/foo.pem
}
The actual implementation is based off doas' parse.y. This gave us
various benefits, like cleaner code, \ to break long lines, better
handling of quotes etc...
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.
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.
Omar Polo
Stephen Gregoratto
Anna “CyberTailor”