ietf-corpus

rfc-4266

The gopher URI Scheme

P. Hoffman
date2005-11 streamIETF wgnon working group statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc4266 doi10.17487/RFC4266
This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

obsoletes

Extracted elements (16)

design-rationale §2.3

Gopher+ was uncommon even when Gopher was popular. The Gopher+ extensions are preserved in the URI scheme for completeness but are largely of historical interest.

design-rationale §1

This document was created solely to allow RFC 1738 to be made obsolete while keeping the gopher URI scheme definition on the standards track. The Gopher protocol itself was widely used in the early 1990s but few servers remain in use today.

process

design-rationale §2.1

Within the <gopher-path>, no characters are reserved. This differs from other URI schemes that reserve certain characters for special purposes.

interoperability-note §2.1

Some Gopher selector strings begin with a copy of the <gophertype> character, causing that character to appear twice consecutively in the URI path. Implementations must handle this case correctly.

protocol-element §2.4

A Gopher+ string of '+' refers to the default view (data representation) of a Gopher+ item. A Gopher+ string of '?' refers to an item with a Gopher+ electronic form (+ASK) associated with it.

protocol-element §2.2

For Gopher search engines, the selector is followed by an encoded tab (%09) and the search string. The Gopher client sends the decoded selector, a literal tab, and the search string to the server.

protocol-element §2.5

Gopher+ items tagged with '?' have a +ASK form; the client must fetch the item's +ASK attribute to get the form definition, collect user input, and return responses with the selector string to retrieve the item.

protocol-element §2.7

Specific Gopher+ attributes are referenced using '!<attribute_name>' or '$<attribute_name>'. Multiple attributes are separated by coded spaces (%20), e.g., '!+ABSTRACT%20+SMELL'.

protocol-element §2.1

The Gopher selector string is a sequence of octets that may contain any octets except 0x09 (HT/tab), 0x0A (LF), and 0x0D (CR). The selector string may be empty, which refers to the top-level directory on a Gopher server.

protocol-element §2.1

The gopher URI scheme takes the form gopher://<host>:<port>/<gopher-path>, where <gopher-path> consists of a single-character gophertype followed by an optional selector, search string, and Gopher+ string separated by encoded tabs (%09). If the port is omitted, it defaults to 70.

registry

protocol-element §2.1

The <gophertype> is a single-character field denoting the Gopher type of the resource. If the entire <gopher-path> is empty, the delimiting '/' is optional and gophertype defaults to '1'.

protocol-element §2.6

To refer to Gopher+ attribute collections, the Gopher+ string uses '!' for all attributes of a single item, or '$' for all item attributes of all items in a Gopher directory.

protocol-element §2.3

URLs for Gopher+ items include a second encoded tab (%09) and a Gopher+ string. When a Gopher+ string is present, the %09<search> component must also be supplied, though <search> may be empty.

security-consideration §3

The Gopher protocol transmits passwords in cleartext for authentication and offers no privacy mechanisms. Both properties are considered extremely unsafe in current practice. Implementers should refer to the general URI security considerations in RFC 3986.

security, privacy

wire-format §2.8

For Gopher+ alternate views, the Gopher+ string takes the form '+<view_name>%20<language_name>', encoding the view type and language identifier from the item's +VIEW attribute.

wire-format §2.9

The Gopher+ string for an electronic form URL encodes the client-to-server message as '+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A', representing the filled-out ASK block responses.