Zusammenfassung

  • Ein Gopher-Eintrag bestand aus Typ, Anzeigename, undurchsichtigem Selector, Host und Port. Der Mensch wählte den Namen; der Client begann mit den übrigen Feldern eine neue Transaktion.
  • Die sichtbare Hierarchie war ein Graph aus Verweisen. Ein Menübetreiber konnte einen Weg anbieten, ohne den Zielserver zu besitzen oder Echtheit, Bestand und Sicherheit seiner Antwort zu beweisen.

Hinter einem vertrauten Namen konnte ein anderer Betreiber stehen

Ein Student wählt im Hochschulmenü „Vorlesungsverzeichnis“. Die Oberfläche sieht aus, als öffne sie einen Unterordner desselben Systems. Tatsächlich kann der Client die laufende Transaktion beenden und zu einem anderen Host an einem anderen Port wechseln. Die verborgenen Koordinaten standen in derselben Zeile wie der freundliche Name.

RFC 1436 beschreibt die Directory Entity mit fünf Feldern. Ein Zeichen legt den Item Type fest; dann folgen Benutzername, Tab, Selector, Tab, Host, Tab, Port und CRLF. Der Leser sieht gewöhnlich nur den Namen. Der Client erhält einen ausführbaren Wegweiser.

Damit wurde verteiltes Publizieren billig. Eine Abteilung musste fremde Dokumente nicht in ein zentrales Repository kopieren. Eine Zeile genügte. Nach der Auswahl fragte der Client den genannten Dienst direkt.

Die Einsparung begrenzte zugleich die Zuständigkeit. Der Menüherausgeber bestimmte Beschriftung, Reihenfolge und Aufnahme. Der Zielbetreiber bestimmte, was der Selector bedeutete und welche Daten zurückkamen. Einen Weg zu verzeichnen, bedeutete nicht, das Ziel zu beherrschen.

Die Bedeutung des Selectors blieb am Ziel

Selector-Beispiele wirkten oft wie Dateipfade. Dennoch verlangte RFC 1436, dass der String für den Client nichts bedeuten und niemals von ihm verändert werden sollte.

So behielt jeder Server seine interne Freiheit. Einer konnte einen Pfad auflösen, ein anderer ein Skript, eine Anwendung oder eine Abfrage aufrufen. Das gemeinsame Protokoll zwang niemanden, sein Filesystem offenzulegen oder einen weltweiten Objektbezeichner zu übernehmen.

Undurchsichtigkeit war jedoch kein Stabilitätsversprechen. Gleiche Bytes konnten auf zwei Hosts Verschiedenes bezeichnen. Nach einer Migration konnte derselbe Server den String neu auslegen. Der Selector war weder Content Hash noch Berechtigungsnachweis noch dauerhafte Identität. Er galt im lokalen Namensraum des genannten Dienstes.

Darum mussten Beweisdaten die Bytes unverändert festhalten. Das Normalisieren von Schrägstrichen, das Erraten einer privaten Kodierung oder eine gut gemeinte Reparatur konnte unbemerkt ein anderes Objekt anfordern. Interoperabilität beruhte auch auf der Entscheidung, an der falschen Schicht nicht klug sein zu wollen.

Ein Root war ein Einstieg, kein Souverän

Die Filesystem-Metapher machte Navigation verständlich, schrieb dem Netz aber keine Baumstruktur vor. Ein Menü konnte auf Secondary Server, beliebige Internetdienste oder frühere Knoten zurückverweisen. RFC 1436 nennt das Ergebnis einen beliebigen Graphen.

Eine Hochschule konnte einen bekannten Top-Level-Server betreiben, Abteilungseinträge registrieren und den Einstieg für Lastverteilung klonen. Abteilungen durften dennoch eigene Links veröffentlichen. Die Wurzel erleichterte Auffindbarkeit; sie besaß nicht alle erreichbaren Inhalte.

Jeder Übergang berührte mehrere Zuständigkeiten. Das Quellmenü schrieb Namen und Descriptor. Der Zielserver interpretierte den Selector. DNS konnte einen Alias auf eine andere Adresse verschieben. Der Prozess am Port entschied, wer antwortete. Der Client entschied, ob er den Typ verstand. Der Leser wählte nur aus dem Sichtbaren.

Eine Zeile war deshalb ein zeitgebundener Hinweis. Ein Host konnte falsch, ein Selector veraltet und ein Name irreführend sein. DNS konnte sich ändern, ohne dass das Menü editiert wurde. Der Graph blieb durch laufende Kooperation autonomer Parteien nutzbar, nicht durch eine zentrale Besitzordnung.

Die Kontinuität der Reise entstand im Client

Die Basistransaktion war kurz: TCP öffnen, eine möglicherweise leere Selector-Zeile senden, Antwort empfangen. Der Server hielt zwischen Transaktionen keinen Clientzustand. Nur CRLF konnte das oberste Menü anfordern.

Menü- und Textantworten endeten mit einer Zeile aus einem einzelnen Punkt. Begann eine echte Textzeile mit Punkt, fügte der Sender einen weiteren hinzu; der Client entfernte ihn. Binäre Typen hatten eine andere Grenze und liefen bis zum Schließen von TCP.

Ein Close war also nicht immer ein Fehler. Für Binärdaten konnte es das reguläre Ende sein. Umgekehrt bestätigte ein korrekter Punkt nur die Rahmung, nicht den Inhalt. Ein vollständiges Menü konnte tote Ziele enthalten, ein vollständig begrenzter Text das falsche Dokument sein.

Den Eindruck einer Sitzung erzeugte der Client. Er konnte besuchte Orte auf einen Stack legen oder Verzeichnisse cachen. Die aufeinanderfolgenden Server brauchten keinen gemeinsamen Sitzungsdatensatz. Der Pfad entstand aus unabhängigen Austauschvorgängen und lokalem Gedächtnis.

Der Typ wählte das Verfahren, nicht die Wahrheit

Das erste Zeichen steuerte den Client. 0 bedeutete Text, 1 Menü und 7 Indexsuche. Weitere Werte verwiesen auf Binärformate oder Dienste wie CSO, Telnet und TN3270. Einen unbekannten nichtzentralen Typ durfte ein Client ignorieren oder als unbekannt anzeigen.

Das Zeichen war kein Formatbeweis, keine Authentisierung und kein Sicherheitsurteil. Es war ein Dispatch-Hinweis. Ein falsch klassifizierter Eintrag konnte den Client zu einer falschen Transaktion mit einem ansonsten erreichbaren Endpoint führen.

Bei Typ 7 sendete der Client Selector, Tab und Suchtext. Die Antwort war ein virtuelles Menü. Verschiedene Indexserver und Gateways konnten getrennte Bestände abdecken, ohne das Clientmodell zu ändern.

Auch ein Treffer war nur ein Verweis. Der Suchserver entschied über die Übereinstimmung und lieferte Koordinaten; das Ziel kontrollierte die Abfrage. Ein Treffer bewies weder dauerhafte Erreichbarkeit noch korrekte Relevanz oder unveränderten Inhalt.

Die URI konservierte die Anfrageform

RFC 1738 überführte die Koordinaten in eine URL: Host, optionaler Port, ein Zeichen Gophertype und Selector. Ohne Port galt 70; ein leerer Pfad konnte das Top-Level-Menü vom Typ 1 bezeichnen; %09 trennte Suchtext ab.

RFC 4266 bewahrte das Schema später auf dem Standards Track. Eine Route konnte außerhalb ihres Ursprungsmenüs gespeichert und weitergegeben werden.

Die URI fror das Objekt nicht ein. Der Zielserver deutete weiterhin den Selector, DNS konnte sich ändern und am Port konnte ein anderer Prozess laufen. Reproduzierbar wurde die Syntax der Anfrage, nicht ihre Wirkung oder der Inhalt.

Schutz kam ebenfalls nicht hinzu. RFC 1436 erklärte Sicherheitsfragen für unbehandelt. RFC 4266 warnte später vor fehlender Privatsphäre und Klartext-Passwörtern. Eine syntaktisch gültige Route war keine authentisierte Route.

Fünf Felder enthielten eine institutionelle Entscheidung

Wie können viele Herausgeber einen gemeinsamen Informationsraum bilden, ohne ihre Server einem einzigen Verwalter zu übergeben? Gopher gab dem Client die Koordinaten des nächsten Akteurs.

Machtkonzentration blieb möglich. Ein populäres Menü steuerte Sichtbarkeit, ein Index seinen Erfassungsbereich, ein Client die sichtbaren Typen. Doch diese Mächte blieben unterscheidbar und jeweils einem Betreiber zurechenbar.

Die Grenze ist bis heute nützlich: Ein Verzeichnis kann Wege koordinieren und Ziele auffindbar machen. Es wird dadurch nicht zum Eigentümer der Systeme, die seine Einträge nennen.

Quellen