💾 Archived View for gemini.smallweb.space › tech-gemlog › 20240108-scgi-part-iii.gmi captured on 2024-02-05 at 09:37:07. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
You know, I should really take my own advice. More on that in a minute.
I started firing up Molly Brown again (on a different port - I use GmCapsule for my primary) because for some reason I wanted to mess with SCGI again. It was probably because I read some old posts after someone (actually) emailed me about a couple of them. And, well, being a nerd that doesn't always nerd out, why wouldn't I just want to tinker?
It took me far too long to get SCGI working again (new server), and everything was right there, I just didn't pay attention. I got so wrapped up in configurations and sock files and errors logs that I didn't just stop and read through all the documentation, including my own.
Here's a summary of tips to hopefully help others (and me!) figure this out.
With CGI, I was so used to having the server execute the script that I was applying this logic to SCGI, and it's actually reverse - you fire up your script/handler first (manually or otherwise), to receive connections, and THEN you connect to it. Like this:
(SCGI script) <--> sock <--> (Molly Brown) <--> Browser
[1st] [2nd]
1. SCGI script initiated (by user or automated process)
2. SCGI script binds to sock and listens
3. Molly Brown fields SCGI request from user, and passes to the associated sock. This is the sock defined in your molly.conf for the /path/ you specify. This has to be the same sock your SCGI script is bound to.
- Note: You don't manually create sock files, your script does that, but the path has to exist
4. SCGI script proceses request, passes response back through sock to Molly Brown and onto the user
Bottomline: Make sure your molly.conf and your SCGI script are pointing / using the same sock file.
So for instance, I use python for SCGI, per the tutorial in a previous gemlog.
$ pip install scgi $ mkdir ~/gemini/socks $ mkdir ~/gemini/scgi $ vim ~/.config/molly-brown/molly.conf
-- edit this line to point to your sock file (that's created by your SCGI script):
[SCGIPaths] "/app/" = "/home/<user>/gemini/socks/scgi.sock"
-- edit your SCGI script / server / handler
$ vim ~/gemini/scgi/scgi-example.py
-- and ensure this line is pointing to the same sock file as above
SOCK = "/home/<user>/gemini/socks/scgi.sock"
-- Restart molly-brown (as needed)
-- Start the SCGI script
$ python3 ~/gemini/scgi/scgi-example.py
-- Open a gemini browser and navigate to the app:
gemini://<your_server>/app/
If it's all configured correctly, molly-brown will see a user is going to gemini://<your_server>/app/ and see that it's a scgi program. It will then pass the request onto the sock, on which your scgi program is hopefully listening. If successful, it'll process the request and return some result to the sock and display it to the user.
If you get a "file not found" you might be pointing to a sock directory that doesn't exist.
If you get a "connection refused" check that your SCGI script is running, and that you're navigating to the right path used in your molly.conf file, i.e., "/app/" in the example. Also check that the script and molly.conf file are pointing to the same sock file.
-----
2024-01-08
Tags: SCGI, molly brown, socks, sockets
Gritty
Gemini Mention this log
Send replies to:
gritty@smallweb.space