gmid 1.8.6 (tags/1.8.6)
backport of bd8683d0fd36893c18e7271faaa3b9ea67df0695
it's redundant since gmid already fills the script argv with the words extracted from the search string, but 2.0 won't have cgi support and not all fastcgi <-> cgi wrappers follow RFC3875 § 4.4. This can help in preparing scripts for a future when they'll be run under for e.g. slowcgi(8).
backport of 97b306cbee6d105885a761e04274f661a0ec3757 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.
backport of 77718c121f89b39bd0095f10e2dbd2ff9df65281 RFC3875 § 4.1.7 states that "the QUERY_STRING variable contains a URL-encoded search or parameter string".
backport 17493a486c9e6325c3aae74920ddb10958ae2771 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!
backport of 872a717687a377cc02860e44c67dc1934ebfa9cb
backport of 6130e0e and 06035a0
gmid 1.8.5 (tags/1.8.5)
breaks on some distro and needs further investigations; it's not that interesting fortunately.
undocumented flag to dump to stdout the request before doing it. Not useful, it's debugging leftover.
The code in fcgi_req to send the custom params set in the config file was placed inside the conditional for `tls_peer_cert_provided`, so the custom parameters would not be sent if a client certificate is not provided.