💾 Archived View for rawtext.club › ~sloum › geminilist › 001013.gmi captured on 2020-09-24 at 02:10:51. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Sun May 24 05:58:48 BST 2020
- - - - - - - - - - - - - - - - - - -
It was thus said that the Great solderpunk once stated:
On Sat, May 23, 2020 at 12:32:32PM -0400, int 80h wrote:
I still haven't got around to FastCGI but SCGI is pretty easy. SCGI is
basically a netstring with null terminated environmental variables sent
to the server(cgi script)
Just read https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
and, yeah, this looks pretty straightforward. Are you using Sean's
adaptation of CGI variables to Gemini in conjunction with this?
I don't know about 80h, but I know I am. I'm following the spec (whatthere is of it) at
https://web.archive.org/web/20020403050958/http://python.ca/nas/scgi/protocol.txt
(taken from the Wikipedia article about SCGI). From what I can determine(checking Wikipedia, the above article and the Apache documentation) itappears that the Gemini server (or web server in the case of Apache) isexpecting the SCGI program to be running already, and all that happens isthe Gemini (Apache) server connects to it, sends the request and awaits aresponse.
The *only* example lists the following meta-variables (to use RFC-3875terminology):
CONTENT_LENGTH (mandatory for SCGI) SCGI (mandatory for SCGI) REQUEST_METHOD (mandatory for CGI) REQUEST_URI (not part of RFC-3875)
I'm keeping *most* of the RFC-3875 meta-variables except for those thatdon'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 forREQUEST_URI I have GEMINI_URL and GEMINI_URL_PATH (these are now availablein my CGI interface as well). I haven't added REQUEST_URI because it'sunderspecced in my opinion---the example only shows the path portion, and Ihave a workaround in place anyway.
I was going to make SCGI support a handler (like all of my dynamic contentgenerators in GLV-1.12556) but that requires support in the config file andthus leaves users out [1]. I then had an inspired thought (or evil, takeyour pick) to use symbolic links in the filesystem pointing to the server
lrwxrwxrwx 1 spc spc 16 May 24 00:03 foo -
scgi:////tmp/loglrwxrwxrwx 1 spc spc 22 May 23 23:57 here -
scgi://localhost:33333lrwxrwxrwx 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 configfiles for the Gemini server. I'm not saying everybody has to use thissymbolic hack for SCGI---it's just that I'm using this hack for SCGI supportin GLV-1.12556.
I'll report more on this when I have it finished.
-spc
[1] The CGI support in GLV-1.12556 is not a handler, but is a module used by the filesystem handler when it sees a file that is executable. The userdirectory handler uses the filesystem handler, so the use of CGI is transfered to userdirectories as well.