webdev-1996

Persönliche Erinnerung und technische Belege trennen

Der Name: kein Pseudonym, sondern ein technischer Rest

Hinter sslxy steckt keine große Erfindung. Der Name entstand 1996 aus einer technischen Umgebung heraus, in der Namen nicht vor allem gut klingen, sondern funktionieren mussten. Kurz. Eingabefreundlich. In Dateinamen, Logdateien und Accounts ohne Probleme verwendbar.

Der Ursprung lag in einem Test- und Arbeitskontext rund um einen Shell-Account und erste Experimente mit SSL-Software. Aus einem technischen Zusammenhang wie ssl-server-xy wurde eine verkürzte Form, die als Benutzername und Kennung praktikabel war. Genau daraus blieb sslxy übrig.

Das war keine Markenentscheidung. Es war eher das, was in technischen Umgebungen oft passiert: Ein Name wird einmal gebraucht, funktioniert, taucht in Logs, Verzeichnissen und Mail-Kontexten auf und bleibt dann, weil es keinen guten Grund gibt, ihn wieder loszuwerden.

Entscheidend ist nicht, dass der Name besonders originell gewesen wäre, sondern dass er technisch brauchbar war. Das passt bis heute besser zu ihm als jede spätere rückwirkende Bedeutung.

1996 lag genau zwischen erster Webnormierung und späterer Konsolidierung

Shell-Account und Serverrealität

Webentwicklung 1996 hatte mit dem heutigen Werkzeugpark wenig zu tun. Es gab keinen bequemen Browser-Inspektor, keine Build-Ketten, keine automatisierten Deployments und keine Hosting-Oberfläche, die einem die technischen Details abnahm. Wer etwas ändern wollte, ging auf den Server oder auf einen Shell-Account und arbeitete dort direkt.

Typisch war eine Einwahl über Modem oder ISDN, danach Telnet oder eine ähnliche Terminalverbindung, dazu FTP für Dateiübertragungen. Editiert wurde mit vi, pico oder lokal in einem einfachen Editor mit anschließendem Upload. Schon Zeilenenden konnten Probleme machen. Datei-Rechte mussten stimmen. Pfade mussten stimmen. CGI-Skripte mussten ausführbar sein.

Wenn ein Formular nicht funktionierte, erschien keine freundliche Diagnose im Browser. Stattdessen kam oft nur ein 500 Internal Server Error. Die eigentliche Arbeit begann dann erst: Logdatei öffnen, Interpreter-Pfad prüfen, Dateirechte kontrollieren, Fehlerzeile im Perl-Skript suchen, erneut hochladen, wieder testen.

• Upload und Pflege: per FTP oder direkt im Home-Verzeichnis des Accounts.
• Fehlersuche: primär über rohe HTTP- und CGI-Logdateien.
• Interaktivität: praktisch immer serverseitig, nicht im Browser.
• Werkzeughaltung: kleines Werkzeugset, dafür hohe Kenntnis der Grundlagen.

Diese Umgebung prägte eine Form der Nüchternheit, die später geblieben ist. Wenn jeder Fehler unmittelbar sichtbar und jede Korrektur manuell ist, lernt man früh, unnötige Komplexität zu vermeiden.

Home-Verzeichnis, Document Root und cgi-bin waren verschiedene Ebenen

Ein Shell-Account bedeutete nicht automatisch, dass jede Datei öffentlich im Web lag. Das Home-Verzeichnis gehörte zum Benutzerkonto; der Webserver veröffentlichte nur den dafür konfigurierten Dokumentbereich. Je nach Hostingumgebung konnte dieser beispielsweise über ein Verzeichnis wie public_html oder einen serverseitig definierten Document Root angebunden sein.

Diese Beispiele werden bewusst nicht als persönliche exakte Verzeichnisnamen ausgegeben. Entscheidend ist die damalige Trennung von Benutzerkonto, veröffentlichten Dateien und ausführbaren Serverprogrammen.

UNIX-Dateirechte entschieden mit über Erfolg oder Fehler

Der Webserver musste statische Dateien lesen und Verzeichnisse durchlaufen können. CGI-Programme benötigten zusätzlich die passende Ausführbarkeit. Ein korrektes Skript konnte deshalb allein durch falsche Rechte oder Eigentümerzuordnung scheitern.

Zahlenmuster wie 644 oder 755 waren und sind typische Beispiele, aber keine universelle Vorschrift. Die richtige Einstellung hängt von Server, Benutzergruppen und Ausführungsmodell ab.

Telnet und klassisches FTP gehören historisch hierher – nicht als heutige Empfehlung

Telnet war ein etabliertes Protokoll für interaktive Terminalverbindungen. Klassisches FTP regelte Dateiübertragung über getrennte Kontroll- und Datenverbindungen.

Beide gehören in die damalige Webrealität. Aus heutiger Sicht ist jedoch entscheidend, dass klassisches FTP Benutzernamen und Passwörter im Klartext übertrug; die IETF beschrieb dieses Risiko 1997 ausdrücklich in RFC 2228. Für heutige Fernadministration und Dateiübertragung werden sichere, authentisierte Verfahren verwendet.

Deployment war eine sichtbare Kette einzelner Schritte

Gerade bei FTP spielte der Übertragungsmodus eine Rolle: Textdateien konnten im ASCII-Modus behandelt werden, Binärdateien wie Bilder mussten binär beziehungsweise als Image übertragen werden, damit keine Datenkonvertierung sie beschädigte.

URL, Dateipfad und relativer Link sind nicht dasselbe

Auf typischen UNIX-Hosts konnten Groß- und Kleinschreibung im Dateisystem relevant sein. Ein lokal verzeihender Dateiname konnte nach dem Upload deshalb als 404 enden.

HTTP/1.0 machte den Request-/Response-Weg sichtbar

Schon damals half es, Statuscode und Fehlerklasse zu trennen: 200 bedeutete erfolgreiche Antwort, 403 verweigerte Zugriff, 404 fehlende Ressource und 500 einen serverinternen Fehler.

Der Server musste den Medientyp der Datei richtig ausgeben

• text/html: HTML-Dokument.
• text/plain: reiner Text.
• image/gif: GIF-Bild.
• image/jpeg: JPEG-Bild.
• application/octet-stream: allgemeiner Binärdatenstrom.

Falsche Dateiendung, Serverkonfiguration oder CGI-Ausgabe konnte dazu führen, dass ein Browser Inhalt anders behandelte als erwartet.

SSLeay und frühe Sicherheit

Wer heute an HTTPS denkt, denkt an automatisierte Zertifikate, fertige Verwaltungsoberflächen und Hintergrundprozesse, die Erneuerungen still erledigen. In der Mitte der 1990er war das anders. Kryptographie war deutlich handnäher, sperriger und weniger abstrahiert.

SSLeay war eine frühe Kryptographie- und SSL/TLS-Bibliothek, aus deren Linie später OpenSSL hervorging. In der Praxis bedeutete das: Konfigurationsdateien, Kommandozeilenwerkzeuge, manuell erzeugte Schlüssel und Zertifikatsanfragen, dazu das Bewusstsein, dass Verschlüsselung nichts Magisches ist, sondern ein konkret gebauter technischer Ablauf mit vielen Stellen, an denen man Fehler machen konnte.

Gerade diese frühe Nähe zur Technik war wichtig. Sicherheit war nicht bloß ein Schalter in einer Verwaltungsoberfläche, sondern etwas, das man nachvollziehen musste. Das hat ein anderes Verhältnis zu Infrastruktur geschaffen als heutige Werkzeuge, die vieles korrekt verstecken, aber auch vieles erfolgreich entkoppeln.

Aus dieser Phase stammt auch ein Teil der späteren Haltung zu Websicherheit: lieber nachvollziehbare, kleine und kontrollierte Konfigurationen als schwer durchschaubare Komplexität.

SSLeay war die Vorgängerlinie von OpenSSL

SSLeay wurde in den 1990er Jahren von Eric Young mit Tim Hudson entwickelt und als offene SSL-/Kryptographiebibliothek verbreitet. Die OpenSSL-Projektgeschichte beschreibt, dass die erste OpenSSL-Version am 23. Dezember 1998 erschien und auf der SSLeay-Codebasis aufbaute.

Für diese persönliche Seite bedeutet das nicht, dass rückwirkend eine konkrete SSLeay-Version behauptet wird. Belegt wird nur der historische Zusammenhang zwischen dem damaligen SSLeay-Umfeld und der späteren OpenSSL-Linie.

HTML 2.0 und reale Browserpraxis

Historisch sauber muss man zwei Dinge trennen: die formale Spezifikation und die Praxis in den Browsern. Die formale Basis des Webs war 1996 noch stark von HTML 2.0 geprägt. Gleichzeitig nutzten viele Browser bereits Erweiterungen und Funktionen, die nicht zur reinen HTML-2.0-Spezifikation gehörten, später aber üblich oder standardisiert wurden.

Das ist wichtig, weil rückblickend vieles schnell zu einer einzigen Erzählung zusammengeschoben wird. Rein formal war HTML 2.0 schlanker. In der Praxis arbeiteten Entwickler 1996 aber oft schon mit zusätzlichen BODY-Attributen, Tabellen und anderen browsernahen Erweiterungen, weil genau diese Dinge im Alltag halfen.

• HTML 2.0 als Basis: Überschriften, Absätze, Listen, Links, Bilder, einfache Formulare.
• Browserpraxis 1996: Farbangaben im <body>, Tabellen, zusätzliche Präsentationsmittel.
• Wichtige Trennung: weit verbreitet heißt nicht automatisch sauber Teil derselben Spezifikation.

In der täglichen Arbeit spielte diese Unterscheidung für viele Entwickler zunächst keine große Rolle. Entscheidend war, was in Netscape oder dem Internet Explorer tatsächlich funktionierte. Genau daraus entstand die damalige Webpraxis: weniger normrein, aber oft pragmatisch.

Tabellen und CSS1 zeigen, warum 1996 ein Übergangsjahr war

Tabellen gehörten nicht zum Kern von HTML 2.0. RFC 1942 beschrieb im Mai 1996 einen experimentellen Tabellenentwurf. Browser hatten zugleich eigene Erweiterungen, die Entwickler praktisch nutzten.

CSS1 wurde erst am 17. Dezember 1996 W3C Recommendation. Damit gab es am Ende des Jahres erstmals einen stabilen standardisierten Mechanismus, um Präsentation systematischer von HTML-Struktur zu trennen. Verbreitete Browserunterstützung und tatsächliche Alltagspraxis entwickelten sich jedoch schrittweise.

Formular im Browser, Programm auf dem Server

HTML 2.0 definierte Formulare mit GET- und POST-Verarbeitung. Der Browser sammelte Eingaben und schickte sie an eine URL. CGI war eine verbreitete Schnittstelle, über die der Webserver ein externes Programm starten und Requestinformationen übergeben konnte.

CGI verband HTTP-Request und Prozessumgebung

Die genaue CGI-Spezifikation wurde später konsolidiert. Die hier beschriebenen Variablen erklären die damalige Praxis, ohne so zu tun, als sei RFC 3875 von 2004 bereits die Norm des Jahres 1996 gewesen.

500 Internal Server Error war oft nur die sichtbare Spitze

• Interpreterpfad: Shebang zeigt auf einen nicht vorhandenen Interpreter.
• Dateirecht: Skript ist nicht ausführbar.
• Syntax: Perl- oder Skriptfehler beendet den Prozess.
• Header: CGI-Ausgabe beginnt nicht mit gültigen Response-Headern.
• Pfad: relative Datei- oder Modulpfade stimmen im Serverkontext nicht.
• Berechtigung: Skript darf benötigte Datei nicht lesen oder schreiben.

Die Browsermeldung allein erklärte davon wenig. Erst das Error-Log brachte die Fehlersuche auf die richtige Ebene.

Logs waren die eigentlichen Diagnosewerkzeuge

Testen ohne DevTools bedeutete kleinere, direktere Prüfschritte

1. Datei lokal öffnen: grobe Markup- und Pfadfehler erkennen.
2. öffentliche URL direkt abrufen: prüfen, ob wirklich die richtige Serverkopie ausgeliefert wird.
3. Quelltext anzeigen: sehen, was der Browser tatsächlich erhalten hat.
4. Links einzeln prüfen: relative Pfade und Groß-/Kleinschreibung kontrollieren.
5. Formular separat testen: Request und CGI-Ausgabe auf Minimalfall reduzieren.
6. Logs lesen: Browseranzeige und Serverdiagnose zusammenführen.

Vor dem Upload brauchte auch Handarbeit einen Rückfallstand

Ohne Versionsverwaltung war eine lokale Masterkopie oder datierte Sicherung besonders wichtig. Eine funktionierende Datei wurde nicht überschrieben, ohne dass ein Rückweg existierte.

• lokale Masterkopie erhalten.
• vor größeren Änderungen datierte Sicherung anlegen.
• Upload-Liste führen, wenn mehrere Dateien zusammengehören.
• nach Upload öffentliche Fassung erneut abrufen.
• CGI-Skript und abhängige Datendateien gemeinsam sichern.

Was das Web damals konnte – und was nicht

Die Begrenzungen der Zeit waren nicht nur technisch lästig, sondern auch disziplinierend. Gerade weil so vieles noch nicht ging, musste klar sein, was überhaupt die Aufgabe einer Seite war. Das Ergebnis war oft roher, aber auch direkter.

Was stabil funktionierte

• Textstruktur: Überschriften, Absätze, Listen, Zitate. Das Fundament des frühen Webs war Text.
• Links: Der eigentliche Kern des Mediums. Dokumente miteinander verknüpfen funktionierte zuverlässig.
• Bilder: Möglich, aber teuer in Ladezeit und daher bewusster eingesetzt.
• Formulare: Einfach, aber wirksam. Eingabe im Browser, Verarbeitung auf dem Server.

Was fehlte oder nur unzureichend existierte

• Zentrales Styling: Keine heutige Trennung von Struktur und Gestaltung. Änderungen waren oft Datei für Datei Handarbeit.
• Responsivität: Der Gedanke unterschiedlicher Gerätetypen spielte praktisch keine Rolle.
• Komfortable Typografie: Keine Webfonts, kaum echte Kontrolle, starke Abhängigkeit vom Client-System.
• Komfortable Multimedia-Einbettung: Audio und Video waren nicht selbstverständlicher Bestandteil einer Seite.
• Komplexe Interaktivität im Browser: Vieles, was heute clientseitig läuft, musste serverseitig gelöst werden – oder existierte schlicht nicht.

Gerade deshalb war Struktur wichtiger als Dekoration. Wenn eine Seite rein textlich nicht logisch war, half der Rest auch nicht mehr. Diese Lektion ist aus heutiger Sicht fast wertvoller als viele der späteren Bequemlichkeiten.

Die Werkzeuge änderten sich – die technischen Ebenen nicht vollständig

Die Abstraktion ist größer geworden. Der Request muss aber noch immer eine Ressource oder Anwendung erreichen, Rechte müssen stimmen, Fehler müssen beobachtbar sein und ein Deployment braucht einen Rückweg.

Frühe Webprojekte brauchen mehr als einen Screenshot

• Original-HTML und Skripte: unverändert sichern.
• Bilder und Downloads: gemeinsam mit relativer Verzeichnisstruktur erhalten.
• Serverkontext: Document Root, cgi-bin, Rechte und Interpreter dokumentieren.
• Konfiguration: nur soweit vorhanden und ohne Geheimnisse archivieren.
• Logs: Datenschutz und personenbezogene Daten vor einer Veröffentlichung prüfen.
• Provenienz: persönliche Erinnerung, rekonstruierte Technik und externe Standardquelle klar unterscheiden.
• Prüfsummen: wichtige Archivdateien gegen unbeabsichtigte Veränderungen absichern.

Die Haltung, die geblieben ist

Aus diesen frühen Jahren stammt weniger eine Technik als eine Arbeitsweise. Das Entscheidende war nicht, dass man HTML 2.0 kannte oder CGI-Skripte schrieb. Entscheidend war, dass jede Ebene des Systems sichtbar blieb: Markup, Server, Logik, Datei, Rechte, Fehler. Nichts war vollständig wegabstrahiert.

Genau daraus entsteht eine andere Form von Disziplin. Wenn eine Seite mit wenig Mitteln funktionieren muss, denkt man zwangsläufig in Struktur, Reihenfolge und Zweck. Dinge werden nicht hinzugefügt, nur weil sie möglich sind, sondern weil sie benötigt werden.

Das ist der eigentliche Kern, der von 1996 geblieben ist: nicht Nostalgie, sondern Misstrauen gegen unnötigen Überbau. Lieber ein klar lesbares Dokument als ein technisch überladenes Konstrukt. Lieber eine saubere Struktur als ein Effekt, der mehr kaschiert als erklärt.

In diesem Sinn ist sslxy kein bloßer Name aus einer alten Shell-Umgebung. Der Name ist ein Rest. Die Haltung dahinter ist das, was bis heute weiterlebt.

„Ein Name aus der Infrastruktur. Eine Haltung aus der Frühzeit des Webs.“

Technische Referenzen

Die Standards dokumentieren technische Geschichte. Persönliche Aussagen über den eigenen Shell- und sslxy-Kontext stammen aus der eigenen Erinnerung und werden nicht durch die Standarddokumente „belegt“.

1996 war direkte Systemarbeit, nicht nur HTML-Schreiben

Die Webpraxis bestand aus mehreren Ebenen gleichzeitig: Datei, Pfad, Recht, Protokoll, Webserver, CGI-Prozess, Logdatei und Browser. Gerade weil wenig davon verborgen war, musste man Ursache und Wirkung unmittelbar verstehen.

Der persönliche Handle sslxy bleibt ein Rest dieser Infrastruktur. Die wichtigere Kontinuität liegt jedoch in der Arbeitsweise: kleine nachvollziehbare Systeme, direkte Fehlerdiagnose und möglichst wenig unnötiger Überbau.

„Die Oberfläche war klein. Die Verantwortung darunter war vollständig sichtbar.“

Querverweise im SSLXY-Archiv

• Zur SSLXY-Hauptseite
• Erste Webseiten 1995–1996
• Shell-Accounts und Hosts
• CGI und Logfiles
• Schnittstellen
• Server-Härtung
• Datensicherung und Backups
• Webmaster und heutige Arbeitsweise