Sessions for gopher CGI's

	Sessions for gopher CGI's - A proposal
	Thursday May 24 10:32:51 2012

	On the gopher mailing list, participants are discussing a revision
	clarification of the original gopher RFC. This got me thinking abou
	shortcomings of gopher that I have encountered. While this idea doe
	relate directly to the base protocol and design, it is interesting
	nonetheless, so I decided to create a post about it. What follows
	is a loosely and quickly typed out summary of my idea. As a warning
	is fairly long, but I wanted to avoid any ambiguity.

	(NOTE: This will in no way, shape, or form break the original RFC o
	require any work on the client side)

	Gopher moles are plagued by the inability to distinguish individual
	IP addresses come close, but at best, they can only distinguish
	individual computers, not users. This is a feature proposal to add
	servers, and only servers, that would allow a server and mole to tr
	user across multiple connections.

	As I mentioned, the only thing needed for this method to work is a
	server. A client would not need to keep track of cookies which woul
	store a session number. That means that any existing client will wo
	just fine with this.

	Also, just a note. A gopher client cannot track a session via argum
	to a CGI AND prompt a user to enter information. In order to get in
	from the client, we need to store the user's session information
	somewhere other than the cgi's arguments.

	The idea is that the session number will be stored in the URL. A go
	session URL would look like this:

	The important thing about this URL is that "gs-123" doesn't actuall
	on the file system; it is a string which contains the gopher sessio
	number.

	The "gs-" part of the session string is a prefix. This tells the se
	that the next part up to the "/" is the session number (which could
	be digits, or it could be an alphanumeric mix)

	The server would know that since the "gs-123" doesn't exist on the
	filesystem, there is a _possibility_ that "gs-123" is a session num
	The server then checks "gs-123" against its prefix for gopher sessi
	If "gs-123" contains the prefix at the beginning, the server knows
	a session string.

	The server should export "gs-123" into the $SESS_STR environment
	variable, and "123" into the $SESS_NUM environment variable. It wi
	then serve up the file in /users/octotep/sess.cgi. Since this is a
	sess.cgi will execute and be able to access the newly exported
	environment variables.

	Now, ideally, a server wouldn't use this method for every connectio
	only when it needs it (it sort of ruins gopher's hierarchical style
	order to rectify this, I propose an addition to a session-aware gop
	server's gophermap parser. The addition is that:

	STest a gopher session!<TAB>/users/octotep/sess.cgi<TAB>sdf.org<TAB

	should automatically be converted on the fly to:

	1Test a gopher session!<TAB>/gs-123/octotep/sess.cgi<TAB>sdf.org<TA

	This way any gopher client can understand the links it receives.
	Unfortunately this is the clunkiest part of the idea. I think it co
	some work before it's put into any CGI standard for gopher...

	I welcome any comments of criticisms on this idea. Feel free to pos
	ideas on the gopher mailing list, or contact me directly as octotep
	sdf.org