Commit Graph

8 Commits

Author SHA1 Message Date
Omar Polo e0e15c30d7 simplify glob for pem 2021-01-22 17:41:12 +00:00
Omar Polo 609fc9f9d9 use a c program to fill the file
it's several order of magnitude faster than the equivalent shell script
2021-01-22 17:18:55 +00:00
Omar Polo 5c2e310ede brand new regress suite 2021-01-22 16:48:04 +00:00
Omar Polo 12042ad700 add a configure script and some compat
tested on openbsd, alpine and void
2021-01-21 11:57:46 +00:00
Omar Polo 1590277007 conf & vhosts
* 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
2021-01-15 09:17:43 +00:00
Omar Polo 3c1cf9d07c s/uri/iri since we accept IRIs 2021-01-11 13:08:00 +00:00
Omar Polo 33d32d1fd6
implement a valid RFC3986 (URI) parser
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?).
2020-12-25 13:13:12 +01:00
Omar Polo 3e4749f7f9
initial commit 2020-10-02 19:39:00 +02:00