fix IRI-parsing bug Some particularly crafted IRIs can cause a denial of service (DOS). IRIs which have a trailing `..' segment and resolve to a valid IRI (i.e. a .. that's not escaping the root directory) will make the server process loop forever. This is """just""" an DOS vulnerability, it doesn't expose anything sensitive or give an attacker anything else.

fix various compilation errors Include gmid.h as first header in every file, as it then includes config.h (that defines _GNU_SOURCE for instance). Fix also a warning about unsigned vs signed const char pointers in openssl.

[cgi] split the query in words if needed and add them to the argv

[iri] accept also : and @ again, to be RFC3986 compliant.

don't %-decode the query

bring the CGI implementation in par with GLV-1.12556

ensure iri.host isn't NULL

accept a wider range of UNICODE codepoints while parsing hostnames

legibility: use p[n] instead of (*(p + n))

trim_req_iri: set error string

trim initial forward slashes this parse gemini://example.com///foo into an IRI whose path is "foo". I'm not 100% this is standard-compliant but: 1. it seems a logical consequence of the URI/IRI cleaning algo (where we drop sequential slashes) 2. practically speaking serving file a sequence of forward slashes doesn't really make sense, even in the case of CGI scripts

wording

check also that the port number matches

style

normalize host name when parsing the IRI RFC3986 3.2.2 "Host" says that > Although host is case-insensitive, producers and normalizers should > use lowercase for registered names and hexadecimal addresses for the > sake of uniformity, while only using uppercase letters for > percent-encodings. so we cope with that.