What Kind of Weirdo Uses Gopher?
Me. I do.
At least, I do since yesterday. Not for any good reason, I just thought it would be a fun thing to do. It turns out to actually be a lot easier than setting up an HTTP server, so I thought I'd share the process here in case anybody else is interested in playing with web protocols developed at the University of Minnesota in the early '90's. Also, shout-out to all my Minnesota friends.
What is Gopher, Anyway?
And why haven't I heard of it until now?
Gopher was originally designed by a team at the University of Minnesota to meet the same needs that HTTP met for CERN: to allow people to share documents with each other over a computer network. The main difference between the two protocols is that while HTTP is document-based, Gopher is all about menus. Everything in Gopher is menu-driven, so when you first talk to a Gopher server you just see a list of things to look at next, much like in a file browser. The other big difference between the two protocols is in the amount of overhead each request brings with it. For example, here is a typical HTTP request and response (shamelessly stolen from Wikipedia).
HTTP 1.1 Request
GET /index.html HTTP/1.1
HTTP 1.1 Response
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/22.214.171.124 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Content-Type: text/html; charset=UTF-8
<title>An Example Page</title>
Hello World, this is a very simple HTML document.
Gopher is much less wordy; the equivalent looks something like this:
iHello World, this is a response from a Gopher server.
That's it. Seriously.
So if Gopher is so great, why does every web site use HTTP these days? Well, there are lots of reasons, but some of the main ones seem to be the following:
- The University of Minnesota started charging a license fee for the Gopher server software, driving away users and developers.
- HTTP and the World Wide Web had more and better publicity.
- HyperText documents can be maintained by users whereas Gopher indices have to be maintained by sysadmins with better things to do.
- Mosaic, the first Web browser, supported both HTTP and Gopher, whereas all of the Gopher clients at the time only supported Gopher.
This is a dramatic oversimplification of what was going on in this area in the early 1990's, so if you're really interested in the history of the early web, I highly recommend this paper by Christopher Lee at the University of Michigan: Where Have all the Gophers Gone? Why the Web beat Gopher in the Battle for Protocol Mind Share.
Whatever the reasons for its waning popularity, Gopher is still a cool protocol and the server is ridiculously easy to set up, so I gave it a try. Here's what I did.
Using the Gopher Protocol
Now, if you want to, you can just type Gopher requests over a Telnet connection, but I didn't find that experience to be a whole lot of fun. A better way to do it is to use a browser. Sadly, while it used to be fairly common, Gopher support doesn't exist in any major browser any more now that Firefox has dumped it. Lucky for us, there are plugins! I use Firefox, so I installed OverbiteFF, but there are solutions for most browsers:
Just kidding, I could only find solutions for Firefox and Chrome (and their derivatives). If you insist on using another browser, there are some Gopher proxies out there that you can try, but otherwise it looks like you're stuck with Telnet.
To make sure your browser is working, try this Gopher link: gopher://gopher.floodgap.com/.
Setting Up a Gopher Server
I used pyGopherd since it was already in the Ubuntu repos. Guess how to install it:
sudo apt-get install pygopherd
The config file for pyGopherd is
/etc/pygopherd/pygopherd.conf, but I didn't need to change any of the defaults to get it working.
By the way, if you know of a better or more actively developed Gopher server, let me know so I can try it out. This one doesn't seem to have been touched since 2008.
The installation script for the pyGopherd package creates the directory
/var/gopher, which is where all of your Gopher files will live. Inside it, you will find the file
gophermap, which is the equivalent of
index.html on an HTTP server. This is what users will see when they connect to your server.
The syntax of the menu file is simple. Each item must have one of the following types:
- 0 = plain text file
- 1 = directory menu listing
- 2 = CSO search query
- 3 = error message
- 4 = BinHex encoded text file
- 5 = binary archive file
- 6 = UUEncoded text file
- 7 = search engine query
- 8 = telnet session pointer
- 9 = binary file
- g = GIF image
- h = HTML file
- i = informational message
So, if we have a text file and a folder full of images (let's call it
/images) on our Gopher server,
gopher.example.com, then the main menu might look like this (note that pyGopherd automatically adds
i before any naked lines):
Welcome. Please enjoy some text and images.
1Images /images gopher.example.com 70
0Oh, and a text file secrets.txt gopher.example.com 70
The fields in the links are tab-separated, but the structure should be pretty clear: Link text \t file name or path \t server \t port. That's it. You can stick a
gophermap file in each folder if you want to, but they'll be automatically generated by the server if you don't.
Being Slightly Cleverer
I wanted to be a little bit cleverer since I have Apache running on the same box serving HTTP requests. I decided to set up a subdomain for Gopher and wanted to make Apache redirect to it if somebody tried to make an HTTP request. Here's the relevant virtual host from the config file for peterbeard.co:
RedirectPermanent / gopher://gopher.peterbeard.co
So anyway, my Gopher server is happily serving requests at gopher.peterbeard.co. There's not a whole lot there right now other than some PDFs and some stupid pictures I've collected from 4chan, but it's neat to know that only the cool kids can get to them.