Hubbry Logo
Gopher (protocol)Gopher (protocol)Main
Open search
Gopher (protocol)
Community hub
Gopher (protocol)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Gopher (protocol)
Gopher (protocol)
from Wikipedia

Internet history timeline

Early research and development:

Merging the networks and creating the Internet:

Commercialization, privatization, broader access leads to the modern Internet:

Examples of Internet services:

The Gopher protocol (/ˈɡfər/ ) is a communication protocol designed for distributing, searching, and retrieving documents in Internet Protocol networks. The design of the Gopher protocol and user interface is menu-driven, and presented an alternative to the World Wide Web in its early stages, but ultimately fell into disfavor, yielding to Hypertext Transfer Protocol (HTTP). The Gopher ecosystem is often regarded as the effective predecessor of the World Wide Web.[1][2]

Usage

[edit]
Firefox 1.5 (2005)

The Gopher protocol was invented by a team led by Mark P. McCahill[3] at the University of Minnesota. It offers some features not natively supported by the Web and imposes a much stronger hierarchy on the documents it stores. Its text menu interface is well-suited to computing environments that rely heavily on remote text-oriented computer terminals, which were still common at the time of its creation in 1991, and the simplicity of its protocol facilitated a wide variety of client implementations.

Gopher's hierarchical structure provided a platform for the first large-scale electronic library connections.[4] The Gopher protocol is still in use by enthusiasts, and although it has been almost entirely supplanted by the Web, a small population of actively maintained servers remains.[2]

Origins

[edit]

The Gopher system was released in mid-1991 by Mark P. McCahill, Farhad Anklesaria, Paul Lindner, Daniel Torrey, and Bob Alberti of the University of Minnesota in the United States.[5] Its central goals were, as stated in RFC 1436:

  • A file-like hierarchical arrangement that would be familiar to users.
  • A simple syntax.
  • A system that can be created quickly and inexpensively.
  • Extensibility of the file system metaphor; allowing addition of searches for example.

Gopher combines document hierarchies with collections of services, including WAIS, the Archie and Veronica search engines, and gateways to other information systems such as File Transfer Protocol (FTP) and Usenet.

The general interest in campus-wide information systems (CWISs) in higher education at the time,[6] and the ease of setup of Gopher servers to create an instant CWIS with links to other sites' online directories and resources, were the factors contributing to Gopher's rapid adoption.

The name was coined by Anklesaria as a play on several meanings of the word "gopher".[7] The University of Minnesota mascot is the gopher,[8] a gofer is an assistant who "goes for" things, and a gopher burrows through the ground to reach a desired location.[9]

Decline

[edit]

The World Wide Web was in its infancy in 1991, and Gopher services quickly became established.[10] By the late 1990s, Gopher had ceased expanding. Several factors contributed to Gopher's stagnation:

  • In February 1993, the University of Minnesota announced that it would charge licensing fees for the use of its implementation of the Gopher server.[11][9] Users became concerned that fees might also be charged for independent implementations.[12][13] Gopher expansion stagnated, to the advantage of the World Wide Web, to which CERN disclaimed ownership.[14] In September 2000, the University of Minnesota re-licensed its Gopher software under the GNU General Public License.[15]
  • Gopher client functionality was quickly duplicated by the early Mosaic web browser, which subsumed its protocol.
  • Gopher has a more rigid structure than the free-form HyperText Markup Language (HTML) of the Web. Every Gopher document has a defined format and type, and the typical user navigates through a single server-defined menu system to get to a particular document. This can be quite different from the way a user finds documents on the Web.
  • Failure to follow the open systems model and bad publicity in comparison to the World Wide Web[16]

Gopher remains in active use by its enthusiasts, and there have been attempts to revive Gopher on modern platforms and mobile devices. One attempt is The Overbite Project,[17] which hosts various browser extensions and modern clients.

Server census

[edit]
Number of Gopher servers from 2012 to 2022
  • As of 2012, there remained about 160 gopher servers indexed by Veronica-2,[18] reflecting a slow growth from 2007 when there were fewer than 100.[19] They are typically infrequently updated. On these servers, Veronica indexed approximately 2.5 million unique selectors. A handful of new servers were being set up every year by hobbyists with over 50 having been set up and added to Floodgap's list since 1999.[20] A snapshot of Gopherspace in 2007 circulated on BitTorrent and was still available in 2010.[21] Due to the simplicity of the Gopher protocol, setting up new servers or adding Gopher support to browsers is often done in a tongue-in-cheek manner, principally on April Fools' Day.[22]
  • In November 2014 Veronica indexed 144 gopher servers,[18] reflecting a small drop from 2012, but within these servers Veronica indexed approximately 3 million unique selectors.
  • In March 2016 Veronica indexed 135 gopher servers,[18] within which it indexed approximately 4 million unique selectors.
  • In March 2017 Veronica indexed 133 gopher servers,[18] within which it indexed approximately 4.9 million unique selectors.
  • In May 2018 Veronica indexed 260 gopher servers,[18] within which it indexed approximately 3.7 million unique selectors.
  • In May 2019 Veronica indexed 320 gopher servers,[18] within which it indexed approximately 4.2 million unique selectors.
  • In January 2020 Veronica indexed 395 gopher servers,[18] within which it indexed approximately 4.5 million unique selectors.
  • In February 2021 Veronica indexed 361 gopher servers,[18] within which it indexed approximately 6 million unique selectors.
  • In February 2022 Veronica indexed 325 gopher servers,[18] within which it indexed approximately 5 million unique selectors.

Technical details

[edit]

The conceptualization of knowledge in "Gopher space" or a "cloud" as specific information in a particular file, and the prominence of the FTP, influenced the technology and the resulting functionality of Gopher.

Gopher characteristics

[edit]

Gopher is designed to function and to appear much like a mountable read-only global network file system (and software, such as gopherfs, is available that can actually mount a Gopher server as a FUSE resource). At a minimum, whatever can be done with data files on a CD-ROM, can be done on Gopher.

A Gopher system consists of a series of hierarchical hyperlinkable menus. The choice of menu items and titles is controlled by the administrator of the server.

Similar to a file on a Web server, a file on a Gopher server can be linked to as a menu item from any other Gopher server. Many servers take advantage of this inter-server linking to provide a directory of other servers that the user can access.

Protocol

[edit]

The Gopher protocol was first described in RFC 1436. Internet Assigned Numbers Authority (IANA) has assigned Transmission Control Protocol (TCP) port 70 to the Gopher protocol. The protocol is simple to negotiate, making it possible to browse without using a client.

User request

[edit]

First, the client establishes a TCP connection with the server on port 70, the standard gopher port. The client then sends a string followed by a carriage return followed by a line feed (a "CR + LF" sequence). This is the selector, which identifies the document to be retrieved. If the item selector were an empty line, the default directory would be selected.

Server response

[edit]

The server then replies with the requested item and closes the connection. According to the protocol, before the connection closes, the server should send a full-stop (i.e., a period character) on a line by itself. However, not all servers conform to this part of the protocol and the server may close a connection without returning a final full-stop. The main type of reply from the server is a text or binary resource. Alternatively, the resource can be a menu: a form of structured text resource providing references to other resources.

Because of the simplicity of the Gopher protocol, tools such as netcat make it possible to download Gopher content easily from a command line:

$ echo jacks/jack.exe | nc gopher.example.org 70 > jack.exe

The protocol is also supported by cURL since 7.21.2-DEV, which was released in 2010.[23]

Search request

[edit]

The selector string in the request can optionally be followed by a tab character and a search string. This is used by item type 7.

Source code of a menu

[edit]

Gopher menu items are defined by lines of tab-separated values in a text file. This file is sometimes called a gophermap. As the source code to a gopher menu, a gophermap is roughly analogous to an HTML file for a web page. Each tab-separated line (called a selector line) gives the client software a description of the menu item: what it is, what it is called, and where it leads to. The client displays the menu items in the order that they appear in the gophermap.

The first character in a selector line indicates the item type, which tells the client what kind of file or protocol the menu item points to. This helps the client decide what to do with it. Gopher's item types are a more basic precursor to the media type system used by the Web and email attachments.

The item type is followed by the user display string (a description or label that represents the item in the menu); the selector (a path or other string for the resource on the server); the hostname (the domain name or IP address of the server), and the network port.

All lines in a gopher menu are terminated by "CR + LF".

Example of a selector line in a menu source: The following selector line generates a link to the "/home" directory at the subdomain gopher.floodgap.com, on port 70. The item type of 1 indicates that the linked resource is a Gopher menu itself. The string "Floodgap Home" is what the client will show to the user when visiting the example menu.

1Floodgap Home	/home	gopher.floodgap.com	70
Item type User display string Selector Hostname Port
1 Floodgap Home /home gopher.floodgap.com 70

Item types

[edit]

In a Gopher menu's source code, a one-character code indicates what kind of content the client should expect. This code may either be a digit or a letter of the alphabet; letters are case-sensitive.

The technical specification for Gopher, RFC 1436, defines 14 item types. The later gopher+ specification defined an additional 3 types.[24] A one-character code indicates what kind of content the client should expect. Item type 3 is an error code for exception handling. Gopher client authors improvised item types h (HTML), i (informational message), and s (sound file) after the publication of RFC 1436. Browsers like Netscape Navigator and early versions of Microsoft Internet Explorer would prepend the item type code to the selector as described in RFC 4266, so that the type of the gopher item could be determined by the url itself. Most gopher browsers still available, use these prefixes in their urls.

Canonical types
0 Text file
1 Gopher submenu
2 CCSO Nameserver
3 Error code returned by a Gopher server to indicate failure
4 BinHex-encoded file (primarily for Macintosh computers)
5 DOS file
6 uuencoded file
7 Gopher full-text search
8 Telnet
9 Binary file
+ Mirror or alternate server (for load balancing or in case of primary server downtime)
g GIF file
I Image file
T Telnet 3270
gopher+ types
: Bitmap image
; Movie file
< Sound file
Non-canonical types
d Doc. Seen used alongside PDF and .doc files
h HTML file
i Informational message, widely used.[25]
p image file "(especially the PNG format)"
r document RTF file ("Rich Text Format")
s Sound file (especially the WAV format)
P PDF (Portable Document Format) file
X XML (Extensible Markup Language) file

Here is an example gopher session where the user requires a gopher menu (/Reference on the first line):

/Reference
1CIA World Factbook     /Archives/mirrors/textfiles.com/politics/CIA    gopher.quux.org 70
0Jargon 4.2.0   /Reference/Jargon 4.2.0 gopher.quux.org 70      +
1Online Libraries       /Reference/Online Libraries     gopher.quux.org 70     +
1RFCs: Internet Standards       /Computers/Standards and Specs/RFC      gopher.quux.org 70
1U.S. Gazetteer /Reference/U.S. Gazetteer       gopher.quux.org 70      +
iThis file contains information on United States        fake    (NULL)  0
icities, counties, and geographical areas.  It has      fake    (NULL)  0
ilatitude/longitude, population, land and water area,   fake    (NULL)  0
iand ZIP codes. fake    (NULL)  0
i       fake    (NULL)  0
iTo search for a city, enter the city's name.  To search        fake    (NULL) 0
ifor a county, use the name plus County -- for instance,        fake    (NULL) 0
iDallas County. fake    (NULL)  0

The gopher menu sent back from the server, is a sequence of lines each of which describes an item that can be retrieved. Most clients will display these as hypertext links, and so allow the user to navigate through gopherspace by following the links.[5] This menu includes a text resource (itemtype 0 on the third line), multiple links to submenus (itemtype 1, on the second line as well as lines 4–6) and a non-standard information message (from line 7 on), broken down to multiple lines by providing dummy values for selector, host and port.

[edit]

Historically, to create a link to a Web server, "GET /" was used as a pseudo-selector to emulate an HTTP GET request.[26] John Goerzen created an addition[27] to the Gopher protocol, commonly referred to as "URL links", that allows links to any protocol that supports URLs. For example, to create a link to http://gopher.quux.org/, the item type is h, the display string is the title of the link, the item selector is "URL:http://gopher.quux.org/", and the domain and port are that of the originating Gopher server (so that clients that do not support URL links will query the server and receive an HTML redirection page).

Gopher+

[edit]

Gopher+ is a forward compatible enhancement to the Gopher protocol. Gopher+ works by sending metadata between the client and the server. The enhancement was never widely adopted by Gopher servers.[28][29][30] The client sends a tab followed by a +. A Gopher+ server will respond with a status line followed by the content the client requested. An item is marked as supporting Gopher+ in the Gopher directory listing by a tab + after the port (this is the case of some of the items in the example above).

Other features of Gopher+ include:

  • Item attributes, which can include the items
    • Administrator
    • Last date of modification
    • Different views of the file, like PostScript or plain text, or different languages
    • Abstract, or description of the item
  • Interactive queries

Client software

[edit]

Gopher clients

[edit]

These are clients, libraries, and utilities primarily designed to access gopher resources.

Client Updated License Language Type Notes
ACID 2021 ? C GUI (Windows) Supports page cache, TFTP and has G6 extension.
Bombadillo 2022 GPLv3 Go TUI (Linux, BSD, macOS) Supports Gopher, Gemini, Finger
elpher 2022 GPLv3 Emacs Lisp TUI/GUI Elpher: a gopher, finger, and gemini client for GNU Emacs
eva 2022 GPLv3 Rust GUI (Linux, FreeBSD) Eva (as in extra vehicular activity, or spacewalk) is a Gemini and Gopher protocol browser in GTK 4.
Gopher Browser 2019 Closed source VB.NET GUI (Windows)
Gopher Client 2018 App (iOS)[31] Supports text reflow, bookmarks, history, etc.
gophercle 2022 MIT Java App (Android) Supports only basic functionalities like bookmarks, session-history, downloads, etc.
Gopherus 2020 BSD 2-clause C TUI (Linux, BSD, Windows, DOS) Features bookmarks and page caching.
Gophie 2020 GPLv3 Java GUI (Windows, MacOS, Linux)
Kristall 2020 GPLv3 C++ GUI (Linux) Gemini GUI client with support for Gopher, Finger, and www.
Lagrange 2022 BSD 2-clause C GUI Gemini GUI client with Gopher and finger support. Switches to gophermap/type 1 requests in parent/root navigation.[32]
Little Gopher Client 2019 Pascal Linux, Mac, Windows Sidebar with a hierarchical view
ncgopher 2022 BSD 2-clause Rust TUI ncgopher is a gopher and gemini client using ncurses.
Pocket Gopher 2019 Unlicense Java App (Android) Supports bookmarks, history, downloads, etc.
sacc 2022 C TUI sacc(omys) is a terminal gopher client.
snarf 2020 GPL C CLI Simple Non-interactive All-purpose Resource Fetcher
w3m 2021 MIT C TUI w3m is a text-based web browser

Other clients

[edit]

Clients like web browsers, libraries, and utilities primarily designed to access World Wide Web resources, but which maintain(ed) gopher support.

  • Browse, a browser for RISC OS
  • Camino, versions 1.0 to 2.1.2, always uses port 70.
  • Classilla, versions 9.0 to 9.3.4b1 as of March 2021, hardcoded to port 70 from 9.0 to 9.2; whitelisted ports from 9.2.1
  • cURL, a command line client for accessing URLs for various protocols
  • Dillo+
  • Dooble
  • Edbrowse, a line-oriented editor and browser with an interface like that of ed (text editor)
  • ELinks, versions 0.10.0[33] to 0.12pre6 as of October 2012, unmaintained browser with gopher build option. Fork felinks[34] offers support as a build option
  • Falkon, with plug-in only, requires Falkon ≥ 3.1.0 with both the KDE Frameworks Integration extension (shipped with Falkon ≥ 3.1.0) enabled and the (separate) kio_gopher plug-in[35] ≥ 0.1.99 (first release for KDE Frameworks 5) installed
  • Mozilla Firefox versions 0.1 to 3.6, built-in support dropped from Firefox 4.0 onwards;[36] can be added back by installing one of the extensions by the Overbite Project[17]
  • Galeon version 2.0.7
  • Epiphany, until version 2.26.3, disabled with switch to WebKit
  • Google Chrome, with extension only,[37] Burrow extension[38]
  • Internet Explorer, dropped with version 6: Support removed by MS02-047 from IE 6 SP1 can be re-enabled in the Windows Registry.[39] Always uses port 70. Gopher support was disabled in Internet Explorer versions 5.x and 6 for Windows in August 2002 by a patch meant to fix a security vulnerability in the browser's Gopher protocol handler to reduce the attack surface which was included in IE6 SP1; however, it can be re-enabled by editing the Windows registry. In Internet Explorer 7, Gopher support was removed on the WinINET level.[40]
  • Internet Explorer for Mac version 5.2.3, PowerPC-only
  • K-Meleon, dropped support
  • Konqueror, with plug-in only, requires kio_gopher plug-in[35]
  • libwww, versions 1.0c (December 1992) to 5.4.1 December 2006, libwww is a discontinued API for internet applications. A modern fork is maintained in Lynx
  • Line Mode Browser, since version 1.1, January 1992
  • Lynx
  • Mosaic, version 3.0
  • Netscape Navigator
  • NetSurf, under development, based on the cURL fetcher
  • OmniWeb, since version 5.9.2 (April 2009), first WebKit Browser to support Gopher[41][42]
  • Opera, Opera 9.0 included a proxy capability
  • Pavuk, a web mirror (recursive download) software program
  • SeaMonkey, version 1.0 to 2.0.14, built-in support dropped from version 2.1 onward; could be added back to some versions via Overbite project,[17] but no longer supported.
  • WebPositive, a WebKit-based browser used in the Haiku operating system

Browsers with no Gopher native support can still access servers using one of the available Gopher to HTTP gateways or proxy server that converts Gopher menus into HTML; known proxies are the Floodgap Public Gopher proxy and Gopher Proxy. Similarly, certain server packages such as GN and PyGopherd have built-in Gopher to HTTP interfaces. Squid Proxy software gateways any gopher:// URL to HTTP content, enabling any browser or web agent to access gopher content easily.

For Mozilla Firefox and SeaMonkey, Overbite[17] extensions extend Gopher browsing and support the current versions of the browsers (Firefox Quantum v ≥57 and equivalent versions of SeaMonkey):

  • OverbiteWX redirects gopher:// URLs to a proxy;
  • OverbiteNX adds native-like support;
  • for Firefox up to 56.*, and equivalent versions of SeaMonkey, OverbiteFF adds native-like support, but it is no longer maintained

OverbiteWX includes support for accessing Gopher servers not on port 70 using a whitelist and for CSO/ph queries. OverbiteFF always uses port 70. For Chromium and Google Chrome, Burrow[38] is available. It redirects gopher:// URLs to a proxy. In the past an Overbite proxy-based extension for these browsers was available but is no longer maintained and does not work with the current (>23) releases.[17]

For Konqueror, Kio gopher[43] is available.

As the bandwidth-sparing simple interface of Gopher can be a good match for mobile phones and personal digital assistants (PDAs),[44] the early 2010s saw a renewed interest in native Gopher clients for popular smartphones.

Gopher popularity was at its height at a time when there were still many equally competing computer architectures and operating systems. As a result, there are several Gopher clients available for Acorn RISC OS, AmigaOS, Atari MiNT, Conversational Monitor System (CMS), DOS, classic Mac OS, MVS, NeXT, OS/2 Warp, most Unix-like operating systems, VMS, Windows 3.x, and Windows 9x. GopherVR was a client designed for 3D visualization, and there is even a Gopher client in MOO.[45][46] Most such clients are hard-coded to work on Transmission Control Protocol (TCP) port 70.[47]

Server software

[edit]

Because the protocol is trivial to implement in a basic fashion, there are many server packages still available, and some are still maintained.

Server Developed by Latest version Release date License Written in Notes
Aftershock Rob Linwood 1.0.1 22 April 2004 MIT Java
Apache::GopherHandler Timm Murray 0.1 26 March 2004 GPLv2 or any later version Perl Apache 2 plugin to run Gopher-Server.
Atua Charles Childers 2017.4 9 October 2017 ISC Forth
Bucktooth (gopher link) (proxied link) Cameron Kaiser 0.2.10 10 February 2024 Floodgap Free Software License Perl
Flask-Gopher Michael Lazar 2.2.1 11 April 2020 GPLv3 Python
geomyid Quinn Evans 0.0.1 10 August 2015 BSD 2-clause Common Lisp
geomyidae (gopher link) (proxied link) Christoph Lohmann 0.96 26 August 2022 MIT C REST dynamic scripting, gopher TLS support, compatibility layer for other gophermaps
GoFish Sean MacLennan 1.2 8 October 2010 GPLv2 C
go-gopher James Mills 31 March 2022 MIT Go
Gopher-Server Timm Murray 0.1.1 26 March 2004 GPLv2 Perl
Gophernicus Kim Holviala and others 3.1.1 3 January 2021 BSD 2-clause C
gophrier Guillaume Duhamel 0.2.3 29 March 2012 GPLv2 C
Goscher Aaron W. Hsu 8.0 20 June 2011 ISC Scheme
mgod Mate Nagy 1.1 29 January 2018 GPLv3 C
Motsognir Mateusz Viste 1.0.13 8 January 2021 MIT C extensible through custom gophermaps, CGI and PHP scripts
Pituophis dotcomboom 1.1 16 May 2020 BSD 2-clause Python Python-based Gopher library with both server and client support
PyGopherd Michael Lazar 3.0.1 25 February 2024 GPLv2 Python Also supports HTTP, WAP, and Gopher+
Redis Salvatore Sanfilippo 6.2.5 21 July 2021 3-clause BSD C Support removed in version 7[48]
save_gopher_server SSS8555 0.777 7 July 2020 ? Perl with G6 extension and TFTP
Spacecookie Lukas Epple 1.0.0.0 17 March 2021 GPLv3 Haskell
Xylophar Nathaniel Leveck 0.0.1 15 January 2020 GPLv3 FreeBASIC

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
The Gopher protocol is an application-layer protocol designed for the distribution, search, and retrieval of documents over TCP/IP networks, presenting information in a simple, menu-driven hierarchy that mimics a . Developed in late 1991 at the by a team led by Mark McCahill and including Farhad Anklesaria and Paul Lindner, it originated as a solution to provide campus-wide access to information resources using affordable personal computers, bypassing limitations of the university's mainframe systems. The protocol operates on a client-server model over TCP port 70, where clients send selector strings to servers to request items—such as text files, directories, or search queries—and receive responses as streams terminated by a period on a lone line, with no persistent state maintained between connections. Key features include support for various item types (e.g., files, submenus, and binary data like images), rudimentary hyperlinking via selectors, and integration with search tools like Veronica for indexing menu titles across servers. Gopher rapidly gained popularity in the early , reaching a peak of approximately 6,958 public servers by April 1994 and serving as one of the first widely accessible interfaces for navigating the nascent , often through text-based clients on systems like Unix, Macintosh, and . It introduced concepts such as bookmarks and distributed search that influenced later web technologies, and its free initial distribution via FTP helped democratize online information access before graphical browsers emerged. However, Gopher's growth stalled due to the rise of the , starting with Tim Berners-Lee's 1990 proposal at and accelerated by the 1993 release of the browser, which offered richer hypertext, inline graphics, and greater extensibility through . Compounding this, the University of Minnesota's 1993 imposition of licensing fees for commercial use, in the range of hundreds to thousands of dollars annually—alienated developers and violated the open ethos of the , leading to a sharp decline in adoption; and by early 1995, the number of Gopher servers had declined to around 5,000 as web traffic surged. Despite its obsolescence, Gopher persists in niche communities for its lightweight efficiency and resistance to modern web complexities like advertising and scripting, with ongoing implementations including Gopher+ enhancements and serving as inspiration for modern protocols like Gemini; as of 2020, approximately 395 Gopher servers remained active.

History and development

Origins and creation

The Gopher protocol was developed in early 1991 by a team at the University of Minnesota's Microcomputer Center, led by Mark McCahill, with key contributions from Paul Lindner, Farhad Anklesaria, Bob Alberti, and Daniel Torrey. This effort addressed the shortcomings of existing tools like FTP, which required cumbersome command-line navigation of directory structures, and WAIS, which focused on wide-area searches but lacked seamless integration for campus resources. The developers sought to create a more accessible system for distributing information across TCP/IP networks, particularly for the university's growing need for a campus-wide information system (CWIS). The initial goal was to build a straightforward, menu-driven protocol that enabled easy retrieval of documents and resources without the complexities of hyperlinks or support, prioritizing for non-expert users on early internet infrastructure. Named after the University of Minnesota's mascot, the Golden Gopher, the protocol evoked both the institution's identity and the idea of a "go-fer" that fetches information efficiently. The first public release occurred in April 1991, when Lindner distributed the software via FTP despite internal university resistance to the project. Early implementations ran on UNIX-based systems, with the inaugural server known as "Mother Gopher" initially hosted on a single and later expanded into a cluster of up to 10 Apple IIci computers running Apple's operating system. This modest hardware setup handled the initial load of campus queries, demonstrating the protocol's efficiency in resource-constrained environments.

Adoption and peak usage

Following its initial release in 1991, the Gopher protocol experienced rapid adoption, particularly within academic and research communities. By April 1992, hundreds of Gopher servers were operational worldwide, expanding from its origins at the to include installations at institutions such as and the . By , the number had grown to over 4,800 servers, reflecting the protocol's appeal for distributing documents and resources across the early . This growth was fueled by a 997% increase in Gopher traffic on the NSFNET backbone during 1993, positioning it as the 10th most significant source of packet traffic by September of that year, ahead of the emerging . Key milestones underscored Gopher's expanding ecosystem. In November 1992, the Veronica search engine was released by developers Steven Foster and Fred Barrie at the University of Nevada, Reno, enabling users to index and search across Gopher menus and resources, which dramatically improved discoverability. The first GopherCon conference in 1992, followed by a larger event in April 1993 in Minneapolis with over 250 attendees, fostered collaboration and standardization efforts, including discussions on enhancements like Gopher+. These gatherings, along with informal working groups, helped establish Gopher as a de facto standard for menu-driven navigation in low-bandwidth environments. Institutional adoption was widespread, with universities, libraries, and government agencies leveraging Gopher for resource sharing. The National Science Foundation promoted Gopher through NSFNET, which facilitated its integration into regional hubs at campuses like and , enabling efficient access to research papers, campus directories, and shared files. High-profile implementations included the Gopher server launched in 1993 for public information dissemination, as well as servers by , World Bank, and , highlighting its utility for organized, text-based information retrieval. Gopher's popularity stemmed from its simplicity and speed, particularly in dial-up and low-bandwidth settings, where its menu structure offered a more intuitive alternative to command-line protocols like FTP. This user-friendly design contributed to millions of users accessing Gopher resources by the mid-1990s, making it a cornerstone of early network navigation before the Web's graphical interfaces dominated.

Decline and obsolescence

The decline of the Gopher protocol began in 1993 as the gained momentum through the release of graphical browsers like , which supported content and hyperlinked navigation, surpassing Gopher's limitations to text-based menus and directory structures. This shift was accelerated by the University of Minnesota's announcement at GopherCon '93 of licensing fees for commercial use of Gopher servers, ranging from hundreds to thousands of dollars annually, which alienated developers and users committed to open Internet standards and prompted many to migrate to the royalty-free Web. In response to this backlash, the fees were reduced or eliminated by 1994, but the damage to Gopher's momentum was irreversible, as the commercialization attempt contrasted sharply with the collaborative ethos driving the Web's expansion. By , traffic had begun to plummet while overtook it on the NSFNET backbone, with dropping from 9th to 11th in packet rankings by as the Web rose to 9th. On 30, 1993, CERN's decision to release technology on a royalty-free basis explicitly countered the licensing model and endorsed as an , further sealing 's fate by encouraging widespread adoption of the more flexible protocol. server numbers peaked at approximately 6,958 in 1994 before sharply declining, reflecting the protocol's rapid loss of relevance. In the long term, Gopher's use contracted dramatically, with servers dwindling to a few hundred by 2000 and the protocol persisting mainly in archival or niche applications rather than mainstream navigation. By 1995, Gopher accounted for just 1.5% of NSFNET traffic compared to the Web's dominant share, marking its transition to obsolescence as the standardized around HTTP.

Technical details

Core characteristics

The Gopher protocol employs a text-based, hierarchical system that organizes resources into a structure resembling a , with directories and files accessible through simple client-server interactions over TCP port 70. This allows users to navigate a virtual of items across distributed servers, where each presents selectable entries leading to documents, subdirectories, or search interfaces. The protocol's stateless nature ensures that servers retain no state between transactions, enabling efficient, stateless exchanges that close after each response. Supported document types in the base Gopher protocol are limited to files (type 0), binary files such as DOS binaries (type 5) or Macintosh BinHex archives (type 4), directories (type 1), and search interfaces (type 7), with no native mechanisms for embedding images, hyperlinks, or scripting within menus or documents. Resources are retrieved as streams, requiring clients to handle rendering separately, which keeps the protocol but restricts integration. This focus on basic file types prioritizes textual and searchable content over rich media. Key strengths of include its low overhead and fast retrieval times, particularly suited for bandwidth-constrained networks of the early , where simple text menus load quickly without complex . The protocol's emphasis on ease of use made it accessible to non-experts, presenting a familiar directory-like interface that abstracted the complexities of distributed resources. As a stateless system, it supported scalable deployment across multiple servers without session management burdens. However, Gopher's limitations include challenges with centralized indexing, as it relies on external tools like Veronica for broad searches rather than distributed discovery, leading to potential bottlenecks in resource location. The protocol lacks support for beyond ASCII (with optional ISO Latin-1 extensions), restricting its use in multilingual environments. Additionally, the absence of advanced formatting options confines content to , without capabilities for styled layouts or dynamic elements.

Protocol mechanics

The Gopher protocol operates over TCP connections, with clients establishing a link to servers on port 70, as assigned by the (IANA). Once connected, the client initiates communication by sending a plain ASCII request string consisting of a selector—a path specifying the desired resource—terminated by a and line feed (CRLF). For standard resource retrieval, the selector alone suffices; if the selector is empty, the server typically responds with the root menu. To perform a search, the client appends a tab character followed by the to the selector, forming "selectorsearch terms", which prompts the server to execute a server-side search on the specified indexed resource and return a filtered of results. This search functionality is triggered specifically for resources of type 7 (searchable indexes), where the server processes the query against its indexed content and generates a virtual directory listing matching items. After sending the request, the client awaits the server's response without further input, as the protocol maintains no persistent state across connections. Server responses vary by resource type. For directories or menus, the server streams a series of text lines, each representing an item, with the entire response terminated by a single period on a line by itself ("."); these lines begin with a type indicator (e.g., '0' for a or '1' for a subdirectory menu). For binary files and , the server sends the stream and closes the connection upon completion. Menus and search results are terminated by a single period on a line by itself before closing the connection. Errors are handled by the server sending one or more lines starting with the numeric code '3', followed by a descriptive , before the terminating "."; common errors include invalid selectors or access denials. Upon completing the response, the server closes the connection, ensuring each interaction remains stateless and self-contained. In the Gopher protocol, menus are structured as plain text files consisting of one or more lines, each representing a navigable item in a hierarchical directory system. Each menu line follows a fixed format: a single-character type code, followed by a tab character, the display string (user name, limited to fewer than 70 printable ASCII or ISO Latin-1 characters), another tab, the selector (an opaque up to 255 characters used to retrieve the item), a third tab, the (a ), a fourth tab, and the port number (defaulting to 70 if omitted). The entire menu is terminated by a single line containing only a period (".") followed by a and line feed (CR-LF). This format enables clients to parse and present items without relying on hyperlinks, using selectors to construct retrieval requests to the specified host and port. The type code, the first character of each line, determines the resource type and guides client behavior, such as whether to display the item as text, launch a search, or handle binary data. Standard item types defined in the protocol include:
TypeDescription
0Text file (retrieved and displayed as plain text).
1Gopher submenu (another directory listing).
2CSO phone-book server (for directory searches).
3Error (indicates an invalid or unavailable item).
4BinHex-encoded Macintosh file (decoded by compatible clients).
5DOS binary archive (read until connection closes).
6UNIX UU-encoded file (decoded by clients).
7Index-search server (prompts for a search query appended to the selector).
8Telnet session (initiates a text-based connection).
9Binary file (read until connection closes, for generic binaries).
+Redundant server (duplicate of another item).
TTN3270 session (for IBM mainframe access).
gGIF image file (displayed if client supports graphics).
IImage file (format determined by client).
Clients interpret these type codes to render menus, often using icons, labels, or color-coding for visual distinction—such as folder icons for type 1 submenus or file icons for type 0 text files—while the selector facilitates by forming the path in subsequent requests. An example of raw menu source text might appear as follows (with tabs represented as \t for clarity):

0About Gopher\t/about.txt\tgopher.example.com\t70 1Submenu\t/subdir\tgopher.example.com\t70 7Search Engine\t/search\tsearch.host.com\t70 gImage\t/image.gif\tgopher.example.com\t70 .

0About Gopher\t/about.txt\tgopher.example.com\t70 1Submenu\t/subdir\tgopher.example.com\t70 7Search Engine\t/search\tsearch.host.com\t70 gImage\t/image.gif\tgopher.example.com\t70 .

This snippet illustrates a mix of text file, submenu, search, and image items, ending with the terminating period.

Gopher+ enhancements

Gopher+ was proposed in 1993 by developers at the University of Minnesota's Microcomputer and Workstation Networks Center, including Farhad Anklesaria, Paul Lindner, Mark McCahill, and Daniel Torrey, as an extension to the original protocol to address its limitations and enhance its competitiveness against emerging technologies like the . The enhancements aimed to transform Gopher menu items into more flexible objects with extensible attributes, enabling richer metadata, alternative content representations, and improved resource description while preserving full with existing Gopher clients and servers. Central to Gopher+ are attribute blocks prefixed with a "+" symbol, which servers include in responses to provide additional information about resources. These include the mandatory +INFO block for basic metadata such as the standard Gopher item descriptor, score, and (using ISO-639 codes); the required +ADMIN block containing the administrator's and a modification timestamp in YYYYMMDDhhmmss format; and optional blocks like +VIEWS for listing multiple content formats (e.g., text/plain with size <10k or application/postscript with size <100k, using MIME types) and +ABSTRACT for a brief summary. The +VIEWS feature supports client requests for preferred representations, including -specific variants, allowing servers to offer resources in formats like plain text, PostScript, or binaries with estimated sizes to aid user selection. To access these enhancements, clients modify their requests by appending special characters to the selector string: "!" retrieves all attributes for an item, "$" fetches attributes for an entire directory, and "+" specifies a desired view (e.g., +application/postscript). Servers responding to Gopher+ requests begin with a "+" indicator after the port number in the initial connection line, followed by the attribute blocks in tab-delimited format before delivering the standard Gopher content; non-Gopher+ clients simply ignore the extra lines and process the response as usual. Despite its innovative design, + saw limited adoption, primarily due to its release coinciding with the explosive growth of the in 1993, when browsers like popularized hypertext and multimedia in ways that outshone Gopher's menu-based structure. The enhancements remained backward-compatible, allowing seamless , but the protocol's rigid hierarchy and lack of native hyperlinking contributed to its overshadowed status as surged dramatically compared to Gopher's more modest expansion.

Software implementations

Client applications

The original Gopher client was developed for UNIX systems in 1991 by a team at the University of Minnesota's Microcomputer Center, led by Mark P. McCahill and including Farhad Anklesaria, Paul Lindner, Daniel Torrey, and Bob Alberti; it provided terminal-based menu navigation for accessing distributed documents and integrated support for searching via early tools like Veronica by connecting to dedicated search servers. TurboGopher, released for Macintosh in 1992 and later updated through versions like 2.0.3 in 1995, was optimized for speed in fetching and displaying menus and documents incrementally, supporting menu navigation through a graphical interface and Gopher+ enhancements while allowing Veronica searches via server menus. WS_gopher, an early Windows client with released in 1996, enabled menu-based browsing on DOS and Windows platforms, handling connections for document retrieval and incorporating Veronica integration for cross-server searches. Contemporary clients emphasize simplicity and privacy, often running in text environments without reliance on graphical web technologies. , a longstanding text-based browser originally developed in 1992 and maintained through versions like 2.9.2, natively supports the Gopher protocol alongside HTTP, rendering menus as navigable hyperlinks in terminal sessions for lightweight, accessible browsing. OverbiteWX, a Firefox extension developed by Cameron Kaiser in the with versions released from 2018 onward, restores partial Gopher access by proxying URLs through the Floodgap Public Gopher Proxy, using WebExtensions APIs for compatibility with 57 and later on Windows, macOS, and . Bombadillo, a client for and other systems first released in 2019 by developer sloum, supports alongside Gemini and protocols, featuring vim-like keybindings for menu navigation, a document pager, and configurable settings to prioritize text-only, ad-free exploration. Native browser support for Gopher has diminished; provided partial access via extensions like OverbiteWX until the 2017 transition to WebExtensions in version 57 deprecated legacy add-ons such as OverbiteFF, requiring proxy-based workarounds thereafter. Google Chrome and lack any native or extension-based Gopher support, necessitating external proxies or dedicated clients for access. Gopher clients establish TCP connections on port 70 to servers, sending selector strings to retrieve and render menu items—typically directories, files, or searches—as selectable hyperlinks, ensuring straightforward navigation without complex rendering.

Server implementations

The original Gopher server was developed in 1991 by a team at the University of Minnesota's Microcomputer Center, running on UNIX-based systems such as on Macintosh hardware. This implementation served as the foundation for the protocol, enabling menu-driven access to distributed documents over TCP port 70. Several open-source server implementations emerged in subsequent years, often as forks or reimplementations to support modern environments while maintaining compatibility. PyGopherd, a Python-based server initiated in the early (with initial documentation from 2003), provides multiprotocol support for Gopher, Gopher+, HTTP, and WAP on the same port, including extensible object handling for enhanced functionality. Bucktooth, written in and developed by Cameron Kaiser of Floodgap Systems with version 0.2.10 released on February 17, 2024, emphasizes simplicity and ease of deployment on systems, featuring directory parsing, executable scripting via "moles," and experimental support, though without native TLS. Gophernicus, a C-based server developed for POSIX-compliant systems and actively maintained since at least 2019, offers cross-platform compatibility across Unix variants, including support for user directories, executable item types (enabling CGI-like functionality), and integration with super-servers like or . For modern development, GoGopher is a Go (Golang) library released around 2016 that implements both client and server sides of the protocol, explicitly supporting CGI for dynamic content and Gopher+ for extended attributes. Setting up a server typically involves configuring a whose contents are automatically mapped to menu items and selectors, with files and subdirectories presented as navigable text-based listings; the server listens on TCP port 70 and requires minimal computational resources due to the protocol's lightweight, text-only nature. These implementations remain available primarily for hobbyists and retro-computing enthusiasts, with active maintenance on platforms like ; for instance, SDF Public Access UNIX System hosts a public Gopher space at gopher://sdf.org, allowing users to publish personal content via simple directory setup.

Legacy and modern relevance

Historical impact

The Gopher protocol, developed in 1991 at the , served as a significant precursor to the by introducing menu-based navigation that influenced early browser designs and the broader concept of distributed information systems. Its hierarchical menu structure enabled users to traverse interconnected servers seamlessly, prefiguring the hyperlink-driven exploration of web pages and contributing to the evolution of user-friendly interfaces. For instance, the protocol's integration into the browser in 1993 demonstrated how Gopher's navigation paradigms could be adapted to graphical environments, bridging text-based and visual paradigms in online . Gopher played a pivotal role in the internet's growth by popularizing TCP/IP among non-technical users and acting as a bridge between earlier protocols like FTP and WAIS and the emerging graphical web. By simplifying access to distributed resources through a unified client-server model, it expanded the internet's user base from academic and institutional audiences to a wider , with server counts reaching 6,958 by April 1994 and traffic surging 997% in 1993 alone. This accessibility helped normalize TCP/IP as the foundational suite for everyday , facilitating the rapid dissemination of web technologies and contributing to the internet's transition from a specialized tool to a global medium. Culturally, embodies the pre-commercial internet era, symbolizing an ad-free, text-centric ethos that prioritized content discovery over monetization and influenced later minimalist design philosophies in . Events like the GopherCons from 1992 to 1995 attracted global developers and highlighted its role in fostering collaborative online communities, while its simplicity inspired retro enthusiasts to revive text-based interfaces as antidotes to modern web complexity. This legacy underscores Gopher's position as a hallmark of the 's idealistic origins, before reshaped digital spaces. In comparisons to contemporaries, offered more structured navigation than FTP's command-line file transfers but lacked the flexibility of HTTP, which supported hypertext and integration, ultimately highlighting tensions between proprietary extensions and open standards in protocol evolution. While FTP emphasized raw file exchange without menus, Gopher's item-type system provided a more intuitive directory-like experience; however, HTTP's extensibility allowed for dynamic content, exposing Gopher's limitations in adapting to diverse media formats. These contrasts illuminated early debates on balancing simplicity with innovation in internet standards.

Current usage and revivals

In 2025, the Gopher protocol maintains a modest but dedicated presence with hundreds of active public servers worldwide, as tracked by ongoing indexing efforts that catalog millions of selectors across the network. For instance, Floodgap Systems' Veronica-2 search engine indexes over 5.1 million unique selectors, representing approximately 80% of known Gopherspace, with notable hosts including the community-driven tilde.club and the long-standing SDF Public Access UNIX System. These servers primarily serve text-based content, menus, and files, appealing to users seeking efficient, lightweight access without modern web complexities. Post-2020, Gopher has seen renewed interest as a low-bandwidth, ad-free alternative amid growing concerns over web bloat, surveillance, and resource-intensive browsing. This revival is driven by hobbyists, retro-computing enthusiasts, and those advocating for simpler internet experiences, with projects like Veronica-2 sustaining discoverability by regularly crawling and updating the index of available resources. Community efforts emphasize Gopher's efficiency for constrained environments, fostering a niche ecosystem that contrasts with the dominant HTTP-based web. Gopher finds modern applications among privacy advocates who value its minimalism and lack of built-in tracking mechanisms, as well as in low-resource scenarios such as embedded systems where its plain-text protocol minimizes overhead. Some implementations integrate Gopher with the newer Gemini protocol through multi-protocol clients, enabling hybrid spaces that allow seamless navigation between Gopherspace and Geminispace for enhanced content accessibility without relying on graphical browsers. Despite these developments, Gopher faces challenges including the deprecation of native support in major web browsers—such as removing it in 2011 and never being included in Chrome or —necessitating dedicated clients like OverbiteWX or for full functionality. This reliance limits mainstream adoption, confining usage to specialized tools and communities.

Security considerations

The Gopher protocol transmits all data in over TCP connections on port 70, lacking any built-in mechanisms. This design exposes communications to , where attackers can intercept sensitive information such as document contents or search queries, and to man-in-the-middle (MITM) attacks, enabling data tampering or . Furthermore, the protocol includes no native features, allowing unauthorized access to servers and resources without verification of user or client identity. Key vulnerabilities stem from implementation flaws rather than the protocol specification itself, as security was not addressed in its original design. Historical buffer overflow issues in client and server software, such as the unchecked buffer in Microsoft Internet Explorer's Gopher handler, permitted remote code execution when processing malicious responses from a crafted Gopher server. Similar overflows affected older servers like Gopher 3.0.9, exploitable via specially formatted requests leading to client-side crashes or code injection. Selector strings, used for resource addressing and searches, introduce injection risks if not properly sanitized in implementations, potentially allowing path traversal or unauthorized data access akin to directory traversal attacks. Unlike HTTP, Gopher has no standardized equivalent to HTTPS, leaving it without protocol-level protections against these threats. Modern deployments mitigate these limitations through external tunneling and proxying techniques. Gopher traffic can be secured by proxying over TLS, such as using tools like sslh and relayd to wrap connections in encryption while preserving compatibility with legacy clients via fallback to plaintext. Draft proposals like map Gopher requests to HTTPS exchanges, leveraging TLS 1.3 for confidentiality and integrity without altering the core protocol. In restricted environments, Gopher is often tunneled over SSH for encrypted transport or deployed within air-gapped networks and VPNs to isolate it from untrusted channels. These approaches parallel HTTP's transition to , adapting Gopher for secure use in contemporary infrastructures. Despite its risks, Gopher's simplicity offers security advantages in controlled settings by minimizing the —no support for executable content like reduces exposure to client-side exploits common in web environments. Its low resource footprint facilitates secure deployments on minimal hardware, such as embedded systems or isolated servers, where complexity could introduce additional vulnerabilities. Gopher+ extensions provide basic options, though these are optional and not part of the base protocol.

References

Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.