CGI and client certificate, or do we need a CGI spec

[Sean Conner]

It was thus said that the Great René Wagner once stated:
> I totally agree that we need a definition of what information has to be
> passed to a CGI script by the server. Adjust scripts to honor specific
> server implementations is a no-go.

  I used RFC-3875 for the basis of my CGI support.  It defines the following
variables to be passed to the script.

	AUTH_TYPE

		Only set if a client certificate is present, and if so, I
		set this to "Certificate".  There's another server that sets
		this to "CERTIFICATE".

	CONTENT_LENGTH
	CONTENT_TYPE

		These two don't apply to Gemini, and are thus not set (which
		is allowed per the RFC).

	GATEWAY_INTERFACE

		Always set to "CGI/1.1"

	PATH_INFO

		This is only set if there's additional text past the CGI
		script in the path segment of the request.  If the CGI
		script is "/example/foo" and the request is
		
			gemini://example.net/example/foo

		then this isn't set.  If the request is

			gemini://example.net/example/foo/path/to/something

		then this would be set to

			/path/to/something

	PATH_TRANSLATED

		This is only set if there's additional text past the CGI
		script in the path segment of the request.  This is defined
		as taking the above, and mapping it to the server's document
		structure.  So, if the base directory of the site is
		
			/var/exaple.net/gemini/

		and PATH_INFO is set from the request
		
			gemini://example.net/example/foo/path/to/something

		then this would be set to
		
			/var/example.com/gemini/path/to/something

	QUERY_STRING

		Must always be set.  If no query string is defined, it's set
		to ""

	REMOTE_ADDR
	REMOTE_HOST

		I set these to the IP address of the client (allowed per the
		RFC).  An alternative I've suggested in the past is the use
		of "127.0.0.1" or "::" for these two fields.

	REMOTE_IDENT

		I don't bother with this one---no one runs ident anymore.

	REMOTE_USER

		Only set if a client certificate is present, and if so, the
		concensus seems to be to use the CN field of the subject of
		the certificate, or "" if that isn't present.

	REQUEST_METHOD

		I set this to "", as a request method isn't defined.  Most
		use "GET", which is what Gemini *is*, but personally, I feel
		"" is better as there is no method sent at all.

	SCRIPT_NAME

		If the request is

			gemini://example.net/example/foo

		Then this is set to

			/example/foo

		If the request is:

			gemini://example.net/example/foo/path/to/something

		Then this is still set to:

			/example/foo


	SERVER_NAME
	SERVER_PORT

		Set to the server name and port.

	SERVER_PROTOCOL

		I set this to "GEMINI".  

	SERVER_SOFTWARE

		Up to the server to set as it sees fit.

  And that's it as far as RFC-3875 goes.  Not much to it.  I currently
define only four Gemini specific variables (allowed by the RFC):

	GEMINI_DOCUMENT_ROOT

		Base directory of the site.

	GEMINI_SCRIPT_FILENAME

		This is the full path to the CGI script.

	GEMINI_URL_PATH

		This is the path portion of the Gemini request.

	GEMINI_URL

		This is the request as sent by the client.

  I also define some TLS variables, but those are under discussion elsewhere
on this thread.  These (the TLS and GEMINI variables) can be described in a
companion document, but the base I think should be RFC-3875.  It fits quite
well to Gemini.

  -spc