Thanks for taking the time to write this up! I guess I'm a little surprised / confused to see how closely your implementation sticks to the HTTP version of CGI, i.e. by going to the extent of adding a meaningless dummy environment variable for REQUEST_METHOD because that variable MUST exist in HTTP CGI implementations. I understand this this approach (combined with translating HTTP status codes to Gemini codes) permits existing CGI scripts written for HTTP to be deployed over Gemini without modification, which I suppose is nice, but...I imagine the majority of existing CGI scripts generate HTML output, which, while perfectly cromulent to serve over Gemini, is not really supposed to be mainstream usage. Back when I started work on Shizaru I expected to one day add CGI support and my plan then was to actually *not* set REMOTE_ADDR at all (along with lots of other things, like stripping any Cookie headers out of the response). I see now this would be an RFC violation, but if I ever get around to this, I'll still do it. Shizaru is supposed to be about Doing the Right Thing and creating a subspace of the web where people can relax and feel safe. It's explicitly an opinionated piece of software and I guess you could even call it an activism project, so, well, RFC be damned. To the extent that I presume the majority of CGI scripts for Gemini will be written from scratch for Gemini and so backward compatibility isn't a problem, I wonder if it's worthwhile including something in the spec defining an explicit subset of RFC-3875 as being used for Gemini. This would let us get rid of stuff which is obviously not needed (like REQUEST_METHOD), and gives us the option of maybe getting rid of stuff that maybe we can agree we'd rather not have (like REMOTE_ADDR?). -Solderpunk
---
Previous in thread (1 of 4): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (3 of 4): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)