| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
While here, move the SRCS variable to the configure and add the
-includes in Makefile.local; it de-clutters the Makefile a bit.
|
|
|
|
|
|
|
|
|
|
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
|
|
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.
|
|
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 :)
|
|
https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
|
|
|
|
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...
|
|
|
|
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 :)
|
|
|
|
even the message "sh: etags: not such file or directory" or whatever
seems to be confusing for users, so silent it.
(maybe it would be better not to automatically generate the TAGS, but
it's so handy...)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"test" was replaced by "regress" a while ago
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tested on openbsd, alpine and void
|
|
leftover from when README.md was generated by gmid.1
|
|
we still have an hardcoded list, but this implements the API needed to
modify the mappings.
|
|
cgi.c wasn't really needed; it better to group all the server related
functions together, cgi or not. Now gmid.c contains only startup and
utility code.
|
|
|
|
|
|
this way, we can sandbox the listener with seccomp (todo) or capsicum
(already done) and still have CGI scripts. When we want to exec, we
tell the executor what to do, the executor executes the scripts and
send the fd backt to the listener.
|
|
|
|
|
|
* gmid.c (main): changed behaviour: daemon off by default
(main): changed -c in -C (cert option)
(main): changed -k in -K (key option, for consistency with -C)
(main): added -c to load a configuration
(main): certs, key and doc (-C -K and -d) doesn't have a default value anymore
(handle_handshake): add vhosts support
|
|
|
|
|
|
It's correct, while my hacked valid_multibyte_utf8 would allow things
that aren't technically UTF8.
|
|
Up until now I used a "poor man" approach: the uri parser is barely a
parser, it tries to extract the path from the request, with some minor
checking, and that's all. This obviously is not RFC3986-compliant.
The new RFC3986 (URI) parser should be fully compliant. It may accept
some invalid URI, but shouldn't reject or mis-parse valid URI. (in
particular, the rule for the path is way more relaxed in this parser
than it is in the RFC text).
A difference with RFC3986 is that we don't even try to parse the
(optional) userinfo part of a URI: following the Gemini spec we treat
it as an error.
A further caveats is that %2F in the path part of the URI is
indistinguishable from a literal '/': this is NOT conforming, but due
to the scope and use of gmid, I don't see how treat a %2F sequence in
the path (reject the URI?).
|
