It was thus said that the Great solderpunk once stated: > 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 would think that's now par for course 8-P > 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 did it to see just how difficult it would be, and in fact, it wasn't that difficult at all (well, supporting the command line options of RFC-3875 took a bit of work and I had to change how I parse URLs, but that was the only real snag). > 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. No, but I did have ulterior motives---my web-based blog is CGI based, and I can run it via this module (as long as I enable the http-environment variables). > 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. I might be inclined to set REMOTE_ADDR to "127.0.0.1" and call it a day. That way, any CGI scripts that rely upon that have something, and it doesn't leak any information. And nothing in the RFC state you *have* to set the HTTP related environment variables (or do what I do and set them to "" to prevent CGI scripts from bombing out). I could even do that for my CGI module for Gemini---technically, the CGI script doesn't get raw access to the socket, so the data is "technically" coming from the localhost ... > 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?). Here are the environment variables defined by RFC-3875, and some appropriate ways to handle them: AUTH_TYPE only if a user certificate, then set to "Certificate" CONTENT_LENGTH don't set (it's optional) CONTENT_TYPE don't set (it's optional) GATEWAY_INTERFACE "CGI/1.1" PATH_INFO required under certain conditions (see RFC) PATH_TRANSLATED required under certain conditions (see RFC) QUERY_STRING "" if no query sent, otherwise, query string (this is MANDATORY) REMOTE_ADDR "127.0.0.1" REMOTE_HOST "127.0.0.1" REMOTE_IDENT don't set (it's optional) REMOTE_USER only if a user certificate, then the CN field of the subject REQUEST_METHOD "" SCRIPT_NAME set (see RFC) SERVER_NAME set SERVER_PORT set SERVER_PROTOCOL "GEMINI" SERVER_SOFTWARE set If you *want* to run a web-based CGI script, then the following should probably be defined as: DOCUMENT_ROOT maybe set? (Apache sets this) REQUEST_METHOD "GET" SERVER_PROTOCOL "HTTP/1.0" and translate status codes appropriately. Also, one could define other environment variables starting with "GEMINI_" but I can't think of much that could be set (wait, maybe the TLS client certificate stuff, now that I think about it), but it's allowed under the RFC. Also, some critical environment variables used by the OS like PATH, LANG, etc. I did set up a way to define these (and others) on a global and per-script basis. You don't have to deviate from the RFC *that much.* -spc
---
Previous in thread (3 of 4): 🗣️ Jason McBrayer (jmcbray (a) carcosa.net)