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 (what there 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) 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. The *only* example lists the following meta-variables (to use RFC-3875 terminology): 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 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. 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. 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.
---
Previous in thread (12 of 19): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (14 of 19): 🗣️ solderpunk (solderpunk (a) SDF.ORG)