Gemini and CGI hosting

[solderpunk]

On Sun, May 24, 2020 at 12:58:48AM -0400, Sean Conner wrote:
> 
> From what I can determine
> (checking Wikipedia, the above article and the Apache documentation) it
> appears that the Gemini server (or web server in the case of Apache) is
> expecting the SCGI program to be running already, and all that happens is
> the Gemini (Apache) server connects to it, sends the request and awaits a
> response.

This is precisely what excites me about SCGI.  Until Go gets non-broken
from the perspective of traditional unix user-based permissions, there's
no way for Molly Brown to securely kick off a CGI process via fork().
If something else (a helper program, or the admin) starts the process,
they can presumably start it as a `nobody` user and chroot it somewhere
safe.  It's clunky, but I can live with it for now.
 
>   I'm keeping *most* of the RFC-3875 meta-variables except for those that
> don't really make sense, like GATEWAY_INTERFACE (since it's not),
> SCRIPT_NAME (since it's not a script), PATH_INFO and PATH_TRANSLATED (again,
> becuase it's not a script).  I am keeping REQUEST_METHOD, and for
> REQUEST_URI I have GEMINI_URL and GEMINI_URL_PATH (these are now available
> in my CGI interface as well).  I haven't added REQUEST_URI because it's
> underspecced in my opinion---the example only shows the path portion, and I
> have a workaround in place anyway.

We really need to get the adaptation of RFC-3875 documented somewhere.
Not in the Gemini-spec, but in some kind of side-spec thing, with it's
own name or ID and file in gemini.circumlunar.space/docs/, or a sub
directory thereof.  Not just CGI, but our proposed adaptation of robots.txt,
and other stuff like that.  I dunno what these should be called, I'm not
sure how they should be managed.  I might end up delegating most
responsibility for these "side specs" to interested people who I trust
to do a good job.  I have a bunch of ill-formed ideas for side specs
that it would be good to bring to life.
 
>   I was going to make SCGI support a handler (like all of my dynamic content
> generators in GLV-1.12556) but that requires support in the config file and
> thus leaves users out [1].  I then had an inspired thought (or evil, take
> your pick) to use symbolic links in the filesystem pointing to the server
> 
> lrwxrwxrwx  1 spc spc 16 May 24 00:03 foo -> scgi:////tmp/log
> lrwxrwxrwx  1 spc spc 22 May 23 23:57 here -> scgi://localhost:33333
> lrwxrwxrwx  1 spc spc 22 May 23 23:58 there -> scgi://[fc00::1]:3333/
> 
>   The first points to a Unix domain socket, the other two to TCP sockets. 
> This will give users a way to use SCGI without having access to the config
> files for the Gemini server.  I'm not saying everybody has to use this
> symbolic hack for SCGI---it's just that I'm using this hack for SCGI support
> in GLV-1.12556.  

Nice hack!

Cheers,
Solderpunk