When a matching location has a `fastcgi off' directive, we should
honour that and stop searching for further location which may have
a `fastcgi' directive.
Bug reported by Alex // nytpu, thanks!
There are legitimate cases where SNI can't be used, for example
when connecting via an IPv6 address, so don't rejects those requests.
Instead, fill the requested domain with the address (literal) of
the socket they're connected to and attempt to match on it.
This possibly still incur in a "won't proxy" error if the client
then requests a different hostname.
See the github issue https://github.com/omar-polo/gmid/issues/25
We might end up calling client_close() from start_reply(), but that
will free the fcgi/proxy bufferevent while they're still used on the
stack.
Instead, start_reply() only sets REQUEST_DONE and exits, returning the
error eventually, so callers know when to stop.
this revamps the syntax in the configuration to better match httpd(8)
(and in general be less weird) and to allow per-location fastcgi
configurations.
the bare `param' is now deprecated, but for compatibility it acts
like `fastcgi param' would do now. Same story for `fastcgi <pathÂ>'.
get rid of check_path(), it's overly complicated. Instead, inline
open_file() in client_read() and rework open_dir() to just use
openat() instead of the complicate dance it was doing.
Simplify open_dir() too in the process: if the directory entry for the
index is not a regular file, pretend it doesn't exist.
If a TLS handshake fails there's nothing we can do, so don't attempt
to reply an error (the connected client is not speaking Gemini as
it's not using TLS at all) and instead just close the connection.
Fixes issue #13
Listening by default on all the addresses is so bad I don't know
why I haven't changed this before. Anyway.
Add a `listen on $hostname port $port' syntax to the config file
and deprecate the old "port" and "ipv6" global setting. Still try
to honour them when no "listen on" directive is used for backward
compatibily, but this will go away in the next next version hopefully.
At the moment the `listen on' in server context don't filter the
host, i.e. one can still reach a host from a address not specified
in the corresponding `liste on', this will be added later.
Incorporate the OpenSMTPD' privsep crypto engine. The idea behind
it is to never load the certificate' private keys in a networked
process, instead they are loaded in a separate process (the `crypto'
one) which signs payloads on the behalf of the server processes.
This way, we greatly reduce the risk of leaking the certificate'
private key should the server process be compromised.
This currently compiles only on LibreSSL (portable fix is in the
way).
Was temporarly disabled during the transition to real privsep.
While here, fix a memory leak when using `require client ca'.
Also, avoid leaking info about the parent address space layout to
server processes by not sending pointer values.
Omar Polo