Sessions for gopher CGI's - A proposal
       Thursday May 24 10:32:51 2012
       
       On the gopher mailing list, participants are discussing a revision and 
       clarification of the original gopher RFC. This got me thinking about 
       shortcomings of gopher that I have encountered. While this idea doesn't 
       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, it 
       is fairly long, but I wanted to avoid any ambiguity.
       
       (NOTE: This will in no way, shape, or form break the original RFC or 
        require any work on the client side)
       
       Gopher moles are plagued by the inability to distinguish individual users.
       IP addresses come close, but at best, they can only distinguish 
       individual computers, not users. This is a feature proposal to add to 
       servers, and only servers, that would allow a server and mole to track a 
       user across multiple connections.
       
       As I mentioned, the only thing needed for this method to work is a smart 
       server. A client would not need to keep track of cookies which would 
       store a session number. That means that any existing client will work 
       just fine with this.
       
       Also, just a note. A gopher client cannot track a session via argument 
       to a CGI AND prompt a user to enter information. In order to get info 
       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 gopher 
       session URL would look like this:
       The important thing about this URL is that "gs-123" doesn't actually exist 
       on the file system; it is a string which contains the gopher session 
       number.
       
       The "gs-" part of the session string is a prefix. This tells the server 
       that the next part up to the "/" is the session number (which could only 
       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 number. 
       The server then checks "gs-123" against its prefix for gopher sessions. 
       If "gs-123" contains the prefix at the beginning, the server knows it is 
       a session string.
       
       The server should export "gs-123" into the $SESS_STR environment 
       variable, and "123" into the $SESS_NUM  environment variable. It will 
       then serve up the file in /users/octotep/sess.cgi. Since this is a mole, 
       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 connection, 
       only when it needs it (it sort of ruins gopher's hierarchical style). In 
       order to rectify this, I propose an addition to a session-aware gopher 
       server's gophermap parser. The addition is that:
       
       STest a gopher session!<TAB>/users/octotep/sess.cgi<TAB>sdf.org<TAB>70
       
       should automatically be converted on the fly to:
       
       1Test a gopher session!<TAB>/gs-123/octotep/sess.cgi<TAB>sdf.org<TAB>70
       
       This way any gopher client can understand the links it receives. 
       Unfortunately this is the clunkiest part of the idea. I think it could use 
       some work before it's put into any CGI standard for gopher...
       
       I welcome any comments of criticisms on this idea. Feel free to post 
       ideas on the gopher mailing list, or contact me directly as octotep AT 
       sdf.org