continuation of 6130e0eeac9db4fa8e6fe5934ec2d0ab202f979e

it’s the QUERY_STRING decoded if it’s a search-string (i.e. not a key-value pair.) It’s useful for scripts to avoid percent-decoding the querystring in the most common case of a query, because in Gemini querystrings key-value paired are not common. Idea from a discussion with Allen Sobot.

Spotted the hard way by cage

gmid would disallow the '@' and ':' characters in paths (unless percent-encoded.) Issue reported by freezr.

makes more explicit which fields we're setting. (and kill an extra empty line)

There's no difference, but bzero(3) says STANDARDS The bzero() function conforms to the X/Open System Interfaces option of the IEEE Std 1003.1-2004 (“POSIX.1”) specification. It was removed from the standard in IEEE Std 1003.1-2008 (“POSIX.1”), which recommends using memset(3) instead. so here we are.

I can't think of cases where we reach serialize_iri and path is NULL, but let's keep the safe side and initialize l. gcc 8 found this, clang didn't.

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.

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.