Warum einen kleinen Protokoll-Client neu bauen.
Das Repository begann als visueller Flutter-Prototyp, doch die nützliche Aufgabe lag tiefer: ein Gopher-Menü korrekt parsen, jedes Feld erklären und eine reale Ressource im Terminal ohne unbegrenztes Netzwerkverhalten öffnen.
Browser können die für Gopher nötige rohe TCP-Verbindung nicht herstellen. Statt diese Grenze zu kaschieren, nutzt das Projekt einen Parser in zwei ehrlichen Kontexten: echtes TCP in der CLI und eine deterministische Fixture im öffentlichen Explorer.
Die Protokollgrenzen.
Auch ein kleiner Client braucht klare Netzwerk- und Darstellungsregeln:
- Anfragen besitzen absolute Frist, Idle-Timeout, 8 KiB Obergrenze und eine begrenzte Antwortgröße.
- Binäre Bytes bleiben binär und werden nie direkt in ein interaktives Terminal geschrieben.
- Terminal-Steuersequenzen werden neutralisiert, bevor nicht vertrauenswürdiger Text den Bildschirm erreicht.
- Fehlerhafte Menüzeilen bleiben sichtbar, damit der Explorer Parsing-Fehler nicht in plausible Daten verwandelt.
Ein Parser, zwei Transporte.
Parser und URL-Regeln sind unabhängig von der Netzwerkverbindung nützlich. In der statischen Site machen sie das Protokoll im Browser verständlich und testbar, ohne einen Proxy einzuführen, der das Sicherheitsmodell verändern würde.
Die CLI ergänzt die fehlende Transportgrenze: begrenztes TCP, direkte unverschlüsselte Verbindungen und ausdrückliche Behandlung von Menü-, Text-, Such- und Binäreinträgen.
Der Anfragepfad.
Eine gopher://-URL wird zu Host, Port und Selector. Die CLI sendet den Selector über begrenztes TCP und übergibt die zurückgegebenen Bytes an die gemeinsame Menü-/Textauswertung. Der Browser beginnt an derselben Parsing-Grenze mit einer eingecheckten Fixture.
Entscheidungen für einen verständlichen Client.
Das Projekt bevorzugt sichtbares Protokollverhalten gegenüber bequemer Magie.
Selectors bewahren
RFC 4266-Such-URLs werden geparst, ohne Selector-Punktsegmente zu reduzieren, die zum entfernten Protokollpfad gehören.
Gopher-Selectors verhalten sich nicht wie vertraute HTTP-Pfade; der Unterschied muss sichtbar bleiben.
Im Terminal sicher scheitern
Text wird von Terminal-Steuersequenzen bereinigt; binäre Ressourcen müssen in eine Datei umgeleitet werden.
Der Client verweigert einige bequeme Ausgabewege, weil die Integrität des Terminals wichtiger ist.
Die Web-Demo deterministisch halten
GitHub Pages nutzt eine mitgelieferte Fixture und behauptet nie, einen echten Gopher-Server zu erreichen.
Der Explorer ist eine Lernoberfläche, kein Netzwerk-Client im Browser.
Release-Integrität.
Release-Kandidaten werden zweimal gebaut; npm-Archive und normalisierte SBOM-Evidenz müssen bytegleich sein. Ein Smoke-Test mit sauberem Präfix führt den veröffentlichten Befehl vor dem Release aus.
Die getaggte Veröffentlichung prüft Version, Abstammung von geprüftem main, Checksummen, Attestierungen und unveränderliches Release-Inventar. Der Protokollumfang wächst dadurch nicht: Gopher+, TLS, Telnet, Authentifizierung und automatische Downloads bleiben ausgeschlossen.
Was Benutzer untersuchen können.
Im Terminal lassen sich echte Gopher-Menüs, Texte und Suchen über einen begrenzten Transport öffnen. Im Browser lässt sich eine tastaturbedienbare Fixture durchlaufen und bei jedem Schritt Typ, Selector, Host und Port prüfen.
Das Projekt ist bewusst eng gefasst. Dadurch sind Netzwerkgrenze, Parser-Verhalten und nicht unterstützte Funktionen leicht zu finden.
Evidenzprotokoll.
Protokoll- und Transportaussagen werden durch ausdrückliche Projektgrenzen gestützt:
- Verifikation
- 68 Node.js-Testdeklarationen und zwei Browser-E2E-Deklarationen im auditierten Release.
- Anfragegrenzen
- 8 KiB Anfragegrenze, 5 Sekunden Gesamtablaufzeit, 2,5 Sekunden Idle-Timeout und standardmäßig höchstens 10.000 Menüeinträge.
- Antwortgrenzen
- Standardmäßig 1 MiB Antwortobergrenze und absolut konfigurierbar höchstens 10 MiB.
- Grenze
- Direktes TCP ist unverschlüsselt; TLS, Authentifizierung, Gopher+, Telnet und automatische Downloads werden nicht unterstützt.