Commits
Commit:
54203115cd0121ee0e44f5e58202a4d8054b9c09
From:
Omar Polo <op@omarpolo.com>
Date:
Fri Apr 8 13:52:35 2022 UTC
don't load the built-in list when using `types'
Commit:
d8d170aa5ee1498babee095078b3888f1525a2b3
From:
Omar Polo <op@omarpolo.com>
Date:
Fri Apr 8 13:44:49 2022 UTC
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:
e5d82d9472513ef742dbb0b5ac451337625feb58
From:
Omar Polo <op@omarpolo.com>
Date:
Sat Mar 19 11:02:42 2022 UTC
const-ify some tables matches found with % grep -R '=[ ]*{' . | fgrep -v const
Commit:
1cdea97b6c74ec86e202431a208b5c99343f7273
From:
Omar Polo <op@omarpolo.com>
Date:
Sun Jan 30 10:14:44 2022 UTC
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:
b7967bc1f695126e1bf2705bfd486bbc32aaf8b0
From:
Omar Polo <op@omarpolo.com>
Date:
Sun Jan 2 16:33:28 2022 UTC
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:
7bdcc91ec70ddde092ac5d7b4f75d54915e7b221
From:
Omar Polo <op@omarpolo.com>
Date:
Sat Jan 1 17:08:39 2022 UTC
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:
d49093c105e7e9af2638bce945374ac0036b3498
From:
Omar Polo <op@omarpolo.com>
Date:
Sat Jan 1 16:33:44 2022 UTC
support optional client certificate for proxy rule
Commit:
72b033ef18ae3f82922f6f11ce0f5194e95f667d
From:
Omar Polo <op@omarpolo.com>
Date:
Wed Dec 29 20:36:54 2021 UTC
add ability to proxy requests 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
Commit:
193380eaa4b4fa001dd773b9ee94e2545eed5efa
From:
Omar Polo <op@omarpolo.com>
Date:
Sun Oct 24 16:57:31 2021 UTC
free OCSP path when clearing the config was forgotten in ff05125eb81e5bbf2cf05b8434d03bce584936e0
Commit:
7fa6717647863ac5c63126329c52336409712353
From:
Omar Polo <op@omarpolo.com>
Date:
Fri Oct 15 08:03:11 2021 UTC
fmt
Commit:
ff05125eb81e5bbf2cf05b8434d03bce584936e0
From:
Stephen Gregoratto <dev@sgregoratto.me>
Via:
omar-polo <op@omarpolo.com>
Date:
Fri Oct 15 07:58:23 2021 UTC
Implement OCSP stapling support 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
Commit:
f0a01fc742e83b3f4736b5d64af3ab18148afc5a
From:
Omar Polo <op@omarpolo.com>
Date:
Sat Oct 9 21:40:55 2021 UTC
two -n to dump the parsed configuration 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.
Commit:
807869c14ee57aaa6035e6cba0df5d1369ced9ba
From:
Omar Polo <op@omarpolo.com>
Date:
Thu Oct 7 17:19:45 2021 UTC
print the error too if we can't open a directory It's not intuitive to print open ... for domain xyz it doesn't convey that the open failed. now it appends the error string, at least the user can understand that something went wrong. reported by cage on irc, thanks!
Commit:
4cd25209651f224be8c34d6006ef689963ce37d5
From:
Omar Polo <op@omarpolo.com>
Date:
Thu Oct 7 10:47:02 2021 UTC
one FastCGI connection per client 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...)
Commit:
81e0f0007842bc82fe234ffe4e5e0ce362b3a280
From:
Omar Polo <op@omarpolo.com>
Date:
Fri Sep 24 08:10:07 2021 UTC
fmt
Omar Polo