Gopher's menus are incredibly simple. So simple, in fact you can read them and browse a Gopher server without a client, from the command-line if you really wanted to. All a Gopher menu is at the end of the day is a plain text list of selectors, each one consisting of five bits of information separated by tabs. Because of this simplicity, Gopher menus almost never eclipse more than 5kb in size, making them excellent even on slow connections.
Table of contents
Selector anatomy
So what is a "selector"? A selector is an item on a Gopher menu, most accurately, but generally, it's the things you click on to access other menus, documents on that server, or menus on other servers. Selectors have five parts, the itemtype, the display string, the path, the host, and the port, all tab-separated. In total, these all make up the name of the item, the type of item, and where to get the item on the internet.
So we can break it down, here's what a selector looks like in full:
0Macintosh Prices Prices/Mac pserver.bookstore.umn.edu 70
Itemtype
0
The itemtype is the first letter or digit of a selector, and it tells the client what the item is and how to display the data sent by the server in response to what was requested. See "Valid itemtypes" below for a full list of them.
In our case, 0 is the itemtype, meaning to render the incoming data as plain text.
Display string
Macintosh Prices
The display string is the "name" of the selector. This is the textual representation of what the item is. (There's no tab between the itemtype and the display string, strangely.)
Path
Prices/Mac
The path to the item on the server.
Host
pserver.bookstore.umn.edu
The host is the server that the item resides on. For most selectors, this will be the domain name of the server the menu itself resides on, but if you're linking elsewhere, it'll go elsewhere.
Port
70
Finally, this is the port to send the request on. Gopher's traditional port is 70, and many older clients are hardcoded to work only on port 70. Most often, therefore, you'll see this part set to 70.
Valid itemtypes
RFC1436 specifies 14 canonical (officially-recognized) itemtypes for you to use.
| Itemtype | Description | Handling notes |
|---|---|---|
0 |
Plain text files. It's a good idea to keep as many of the documents on your server as possible as plain text for maximum interoperability between clients. At the very least, it's good to keep plain text copies around. | |
1 |
Gopher directory. | Clients will try to display this as a menu, natch. |
2 |
CCSO server. CCSO was an early stab at a digital phone book, allowing a client to search a name and get contact information or whatever else was stored in that person's file back. Of course, there was no requirement that the information on offer be about people, but that was what it was often used for. | Some Gopher clients have CCSO support built-in, while others don't know what to do with it. Some just outright crash. |
3 |
Error selector. Servers will often return an itemtype of 3 in their error handlers. |
Some clients simply won't display these strings, while others will display them big and bold like errors, appropriately. Either way, probably not a brilliant idea to actually use this selector in your menus. |
4 |
BinHexed file. BinHex was a way to for classic Mac OS users to transmit binary files over email or other systems where the character encoding could not be ensured, like CompuServe, to keep them safe during transit. | |
5 |
"DOS binary archive", namely ZIP archives. The official specification remains agnostic about what specific file type this pertains to, but given the popularity of PKZIP at the time, ostensibly that. | Gopher has really crude handling of binary files, and there's no way to know how big a binary file is before it's all sent. Clients are required by RFC1436 to read until the server closes the TCP connection. As such, I don't recommend sending large files (>50mb) over Gopher. |
6 |
uuencoded file. uuencoding was built on the same principle of protecting binary files across character encodings as BinHex, but for Unix systems (hence "Unix-to-Unix encoding"). | |
7 |
Search server. This is used for both Veronica and full-text search systems like WAIS. | Clients that support searches will ask for a query and send that to the server encoded in the URL. |
8 |
Telnet server. Telnet was an early way to communicate with remote servers, the niche now occupied by ssh. |
I don't know of any Gopher clients that can do Telnet. |
9 |
Generic binary. | Gopher has really crude handling of binary files, and there's no way to know how big a binary file is before it's all sent. Clients are required by RFC1436 to read until the server closes the TCP connection. As such, I don't recommend sending large files (>50mb) over Gopher. |
+ |
Redundant server. The Gopher specification allows for redundant servers to be used for load-balancing purposes or as a backup in case the main server goes down. | I'm not sure how this was implemented on either end of the transaction. |
T |
3270-compatible server. The IBM 3270 was a computer terminal introduced in 1971 and meant to interface with IBM's mainframes. TN3270 is a special variant on the normal Telnet protocol meant specifically for communicating using the 3270 standard. | I don't know of any Gopher clients that can do Telnet. |
g |
GIF image. Yes, surprisingly, the original Gopher spec had an item type specifically for GIFs! I think you know what to do with this information. | |
I |
Generic image file. | It's up to the client how to display this. Web/Gopher clients like OverbiteFF display them inline, while others forward to the system handler for the file type in question. |
Non-canonical itemtypes
Alongside these 14, there are a few commonly-used non-canonical types. You should take care about using these, as some older or more basic clients may not recognize and render them.
| Itemtype | Description | Handling notes |
|---|---|---|
d |
Document. Commonly used for binary documents like Microsoft Word files and PDFs. | |
h |
HTML document. | Web browsers can obviously handle this one no problem. Standalone clients, be careful. |
i |
Informational selector. This is a line of plain text used for adding context to a Gopher menu. | Internet Explorer 6 renders these as links that go nowhere, and some clients outright don't display them at all. |
s |
Sound file. Commonly, this means WAVs. | Netscape 4 actually has a Java applet that plays sound files in a very basic player without having to leave the browser. A really nice addition, honestly. |
Seeing the source code of a menu
Here's a neat trick: go to a Gopher menu online and change the 1 in the URL to a 0.
Yes, the source code to the menu is revealed! This is because the 0 itemtype sends whatever's requested as a text file. For most files you'd find on a Gopher server, stuff like images and compressed archives, this would be utterly useless as they're binary files, thus appearing only as a mess of random characters. Menus, on the other hand, are plain text just like any normal text file, and thus appear totally coherent when retrieved in this manner.
If you're wondering what practical application this has, you can use it for debugging missing selectors in a menu, provided your client doesn't render out the error (3) itemtype, or just for curiosity's sake.
Customizing menus
As Gopher is a document retrieval protocol, it's mostly meant to show you the files in a folder and deliver those files to you. There are two distinct ways to customize a menu, either using .link and .cap files gopherd-style, or using gophermaps Bucktooth-style. Both are explained in my page on customizing Gopher menus.