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!
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.
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!
to connect to unix-domain sockets the `unix' pledge is needed and also
unveil "w". gmid can't mutate files because it doesn't pledge `wpath'
nor `cpath'.
Both Linux and OpenBSD have LOGIN_NAME_MAX available when including
limits.h, FreeBSD, Darwin and possibly others don't.
FreeBSD (and maybe Darwin) have MAXLOGNAME, so try to use that if
available. Otherwise use _POSIX_LOGIN_NAME_MAX, but only has a fallback
since it has a lower value (9 at the time of writing).
If everything fails, use 32 which is what OpenBSD use by default;
OpenSMTPd also defaults to it.
(compat copied from kamid.)
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.