On Mon, Jan 13, 2020 at 06:22:40PM -0500, Sean Conner wrote: > > I was looking over the code for CGI support and I notice we took two very > different approaches to it. I based my support upon RFC-3875, with some > changes to reflect Gemini (and support running existing web-based CGI > programs by mapping the return status codes), while you pretty much just run > the script. I would expect at the very least the QUERY_STRING > meta-variable (as RFC-3875 calls it, or "environment variable" as everybody > else calls them) to be set. > > But given that CGI wasn't specced for Gemini, I think both our > implementations are compliant though. Good eye! I actually intended to post something abou this to the list shortly after implementing that CGI support, but I suppose that must have been around the time things started getting really busy for me. The extremely simple approach to "CGI" (or whatever we want to call dynamic content) in MollyBrown came about mostly because sloum was keen to start playing with dynamic content, so I did the simplest thing that could possibly work - run the script, tell it the corresponding URL over stdin and then close the pipe. It can parse out any user input after a & if it needs it. This decision should not be interpreted as a criticism of your RFC-3875-derived implementation. I think it makes good sense for there to be an option for people to easily convert existing web CGI scripts to Gemini. But I do think it would be nice if there was one vaguely standard way for servers to implement this kind of thing, so that dynamic content generating code could be more portable. I think for that I'd probably prefer something as light as possible, and to explicitly distance Gemini from many of the ideas baked into RFC-3875, especially that dynamic content code should have access to the end user's IP address. I think there's a lot to recommend the way Molly Brown works, especially if we generalise it just a little to "Gemini CGI apps should endlessly read single line URLs over THING, until THING is closed, at which point the app should terminate". Here THING could be stdin, or a TCP connection (making a CGI app basically a small self-contained server), or a unix domain socket. Simple servers could do what Molly currently does, just spawn the script, send a single URL over stdin and then close stdin, giving us the good old fashioned one-process-per-request model of traditional web CGI. But more advanced servers could give admins a way to configure different approaches where the process is persistent, more like FastCGI. Or they could round-robin load balance between multiple servers on a local network. The actual CGI program would see very little difference between these scenarios, you'd just give a slightly different argument to a library function which produced some kind of iterator over URLs. This has great power:weight. I was very happy with this idea until I realised that CGI programs should also have some way to get access to client certificates, not just the URL. :( I haven't returned since then to thinking about how to achieve this. Maybe a good subject for a new thread... Cheers, Solderpunk
---
Previous in thread (2 of 5): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (4 of 5): 🗣️ Sean Conner (sean (a) conman.org)