CGI suport for Gemini

[Sean Conner]

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