💾 Archived View for rawtext.club › ~sloum › geminilist › 001017.gmi captured on 2020-09-24 at 02:10:41. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

<-- back to the mailing list

Gemini and CGI hosting

solderpunk solderpunk at SDF.ORG

Sun May 24 15:44:02 BST 2020

- - - - - - - - - - - - - - - - - - - 

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-brokenfrom the perspective of traditional unix user-based permissions, there'sno 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 somewheresafe. 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'sown name or ID and file in gemini.circumlunar.space/docs/, or a subdirectory 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 notsure how they should be managed. I might end up delegating mostresponsibility for these "side specs" to interested people who I trustto do a good job. I have a bunch of ill-formed ideas for side specsthat 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