libevent2 can still somehowe call client_read even in code paths
that never enable reading from the evbuffer. Can't reproduce on
the libevent in base on OpenBSD. It's a bit ugly, but it's a small
workaround for something that otherwise *always* make gmid crash
when linked against libevent2. (client_read works under the
assumption that c->host != NULL, matched_proxy crashes otherwise.)
The tests are still there, the suite is equivalent to the old one, but
this one is better structured.
The biggest annoyance I had with the old one was that it wasn't
straightforward to test only a specific set of tests. It's still
impossible, but it's way easier to do it now.
This extract all the tests to their own functions. It's overall
better in all possible regards.
While computing the parent directory it an out-of-bound access can
occur, which usually means the server process dies.
In particular, it can be triggered by making a request for a
non-existent file in the root of a virtual host if the path matches
the `cgi` pattern.
Thanks cage for helping in debugging!
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.
Setting the environment variable SKIP_RUNTIME_TESTS to 1 will prevent
the runtime tests. This is useful when running the tests inside a
sandbox.
based on a similar diff by Anna "CyberTailor"
nobody really cares if must_read fails, as it normally shouldn't. It
only clutters the regression tests with scary messages that looks like
failure but are, in fact, expected.
Some particularly crafted IRIs can cause a denial of service (DOS).
IRIs which have a trailing `..' segment and resolve to a valid IRI
(i.e. a .. that's not escaping the root directory) will make the
server process loop forever.
This is """just""" an DOS vulnerability, it doesn't expose anything
sensitive or give an attacker anything else.
Omar Polo
Anna “CyberTailor”