Commits


install gg too


typo


track file dependency using -MMD if available While here, move the SRCS variable to the configure and add the -includes in Makefile.local; it de-clutters the Makefile a bit.


add `gg' to the list of things to clean


remove TAGS and compile_flags.txt from the list of default actions


fix regress when TESTS is more than one word


make clean: don't clean regress, add cleanall for that


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


reimplement gg This is a better version of gg. Initially it grew with flags directly needed to the specific test cases I wanted to write, so it's ugly to use but handy for tests. This is a new and re-thought implementation that it is (hopefully) easier to use both and "curl-like for gemini" but also for scripts and tests cases. One completely new feature is the proxying support with -P to send the request to the given host.


allow to run only a subset of the runtime tests with make TESTS='test_1 test_2 ...' regress now it's possible to run only that specified subset of tests. It's really useful during debugging :)


fix "warning: jobserver unavailable: using -j1" https://www.gnu.org/software/make/manual/html_node/Error-Messages.html


remove last occurrences of lex


drop the dependency on lex by implementing yylex by ourselves 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...


move gg to regress


fastcgi: a first implementation 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 :)