it reached a point where this stuff is not maintenable. I'd like to move forward with gmid, but the restriction of capsicum and the linux environment at large that make landlock unusable (how can you resolve DNS portably when under landlock?) -and don't get me started on seccomp- makes it impossible for me to do any work. So, I prefer removing the crap, resuming working on gmid by cleaning stuff and consolidating the features, improving various things etc... and then eventually see how to introduce some sandboxing again on other systems. Patches to resume sandboxing are, as always, welcome!

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.

RFC3875 § 4.1.7 states that "the QUERY_STRING variable contains a URL-encoded search or parameter string".

this fixes a possible crash if `client_write' closes the connection, because client_close can end up freeing the fastcgi bufferevent while we're looping. We don't support fastcgi multiplexing, so once we get an END_REQUEST there's nothing more to do. Prodded into looking here after a bug report from Allen Sobot, thanks!