Commits
- Commit:
f2f8eb35c86c4e1c1d858e782c864deac0511cd3
- From:
- Omar Polo <op@omarpolo.com>
- Date:
encode file names in the directory index
Spotted the hard way by cage
- Commit:
18bd83915eab0f06b7e2920d0d71a39108b2d641
- From:
- Omar Polo <op@omarpolo.com>
- Date:
sort the MIME mappings and do a binary search to match
- Commit:
54203115cd0121ee0e44f5e58202a4d8054b9c09
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't load the built-in list when using `types'
- Commit:
d8d170aa5ee1498babee095078b3888f1525a2b3
- From:
- Omar Polo <op@omarpolo.com>
- Date:
allow add_mime to fail
add_mime nows allocate dinamically copies of the passed strings, so
that we can actually free what we parse from the config file.
This matters a lot especially with lengthy `types' block: strings that
reach the internal mapping are never free'd, so every manual addition
is leaked.
- Commit:
ea27eaaa83d61792e75858dc624c58fe1fa13dc9
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fix an out-of-bound access in start_cgi
Long time ago, client->req was a static buffer so the memcpy was safe.
However, it's been since moved to a dynamically allocated string, so
it's very often smaller than sizeof(req.buf) (1024), hence the out of
bound access which results in a SIGSEGV very often on OpenBSD thanks to
Otto' malloc.
The situation with the iri parser, client->req and how the request is
forwarded to the other process needs to be improved: this is just a fix
to address the issue quickly, a better one would be to restructure the
iri parser APIs and rethink how the info is forwarded to the ex process.
- Commit:
3fdc457c8db0550a6143ab626bfefe3351ab0b93
- From:
- Omar Polo <op@omarpolo.com>
- Date:
swap try_client_by_id with client_by_id
i.e. allow client_by_id to fail and return NULL.
Initially I thought it was a good idea to shut down a server process
if we receive an invalid client id as reply from one of our requests
to the executor process. This turned out not to be correct since a
client can (read: will) disconnect in the delay beteewn we acknowledge
their request and the cgi script execution.
The fastcgi and proxy handler already handled this situation, so
they're unaffected.
This allows an attacker to make gmid unresponsible by just making
enough requests until they hit the right timing.
- Commit:
1cdea97b6c74ec86e202431a208b5c99343f7273
- From:
- Omar Polo <op@omarpolo.com>
- Date:
allow using a custom hostname for SNI during proxying
add a `sni' option for the `proxy' block: the given name is used instead
of the one extracted by the `relay-to' rule.
- Commit:
e0f6dc646d6c257869c17f16db977cd064262830
- From:
- Omar Polo <op@omarpolo.com>
- Date:
improve proxy error path
properly release everything when during client_close if the request
was managed by a proxy.
- Commit:
ba94a608a89110740cb24ef098c476c84d371918
- From:
- Omar Polo <op@omarpolo.com>
- Date:
add `require client ca' for proxy blocks
refactor the code that calls validate_against_ca into an helper
function to reuse it in both apply_require_ca and (optionally) in
apply_reverse_proxy.
- Commit:
b7967bc1f695126e1bf2705bfd486bbc32aaf8b0
- From:
- Omar Polo <op@omarpolo.com>
- Date:
proxy: allow multiple proxy blocks, matching options and validations
as a side effect the order of the content of a server block is relaxed:
options, location or proxy blocks can be put in any order.
- Commit:
593e412b4988ca8b72bb7ef9b1cc663cb1184215
- From:
- Omar Polo <op@omarpolo.com>
- Date:
allow to disable TLS when proxying requests
- Commit:
c7c8ef448bc8832998606ec217907c7dc66fec6c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
add `protocols' option to `proxy' rule
- Commit:
5128c0b0e3b51737783c4c68c9e34a76ec8c8b0e
- From:
- Omar Polo <op@omarpolo.com>
- Date:
add `verifyname' option for `proxy' rule
- Commit:
7bdcc91ec70ddde092ac5d7b4f75d54915e7b221
- From:
- Omar Polo <op@omarpolo.com>
- Date:
simplify the proxying code
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.
- Commit:
bd5f79542cf6491ed9e30bca926286e3b9e2600c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
update copyright years