erste-webseiten-1995-1996

Persönliche Chronologie und allgemeine Webgeschichte getrennt halten

Die Seite verbindet Erinnerung und Technik, setzt beides aber nicht gleich. Persönliche Datierungen gelten für die eigene Webarbeit; RFC- und W3C-Daten beschreiben den allgemeinen Standardisierungsstand.

Was 1995 daran eigentlich neu war

Rückblickend wirkt es leicht, frühe Webseiten einfach als „den Anfang des Internets“ zu erzählen. So schlicht war es nicht. Vor 1995 gab es längst digitale Praxis: Mailboxen, Bildschirmtext, Modems, Terminalprogramme, Dateiaustausch, Textmasken, Hosts und technische Kommunikation über langsame Leitungen. Neu war nicht das Digitale an sich. Neu war, dass eine Datei nicht nur in einem geschlossenen System stand, sondern als Webdokument öffentlich, direkt und für Fremde abrufbar wurde.

Genau deshalb waren erste Webseiten nicht einfach eine weitere Softwareübung. Sie lagen auf einem Host, mussten übertragen, korrekt abgelegt, sinnvoll benannt und in einer Form geschrieben werden, die von den damaligen Browsern überhaupt lesbar war. Das klingt heute selbstverständlich. Damals war es ein eigener Schritt.

Auch technisch war die Situation anders als später. Es gab keine gewohnte Entwicklungsumgebung, keine Browser-Devtools im heutigen Sinn, keine Komfortkette aus Vorschau, Framework, Paketmanager und Build-Prozess. Man schrieb Textdateien, übertrug sie, rief sie auf, sah sofort, was schief war, und korrigierte wieder auf Datei- und Zeilenebene. Gerade deshalb war die Arbeit direkter – und unbarmherziger.

„Neu war nicht, dass man schon vorher online war. Neu war, dass der Text plötzlich als Seite öffentlich stand.“

1995: die erste reale Veröffentlichung

Für die erste Phase ist mir die zeitliche Trennung wichtig. Im Laufe des Jahres 1995 wurde bereits an einer frühen Website gearbeitet. Öffentlich online ging diese erste Seite jedoch erst am 30.12.1995. Das ist der reale Veröffentlichungsmoment – nicht ein vager Erinnerungswert und auch nicht nachträglich geglättet.

Gerade dieser Unterschied zwischen arbeiten an einer Seite und sie tatsächlich online sehen war damals größer als heute. Eine lokale Datei oder eine halbfertige Struktur bedeutete noch nichts. Erst wenn die Seite auf dem Host lag, über die reale Verbindung erreichbar war und unter ihrer Adresse funktionierte, war sie wirklich da.

Das ist ein kleiner, aber entscheidender Punkt. Viele spätere Erzählungen über frühe Webjahre tun so, als sei zwischen Idee, Datei und öffentlicher Seite kaum ein Unterschied gewesen. In der Praxis war genau diese letzte Stufe die eigentliche Hürde: Leitung, Host, Übertragung, Pfad, Abruf, Anzeige.

1995 ist damit für mich nicht „schon die ganze spätere Webbetreuung“, sondern die Schwelle. Es ist der erste reale Online-Schritt. Die dauerhafte Linie beginnt erst danach.

Vom lokalen Dokument zur öffentlichen HTTP-Antwort

Eine Webseite wird nicht dadurch öffentlich, dass eine HTML-Datei lokal funktioniert. Mehrere unabhängige Ebenen müssen zusammenpassen.

Shell-Account, Hostname und der Ursprung von sslxy

Für die frühe Webarbeit war der Shell-Account zentral. Er war kein dekoratives Zusatzsystem, sondern die eigentliche technische Arbeitsumgebung: Login, Dateien, Pfade, Upload, Logik, erste Skriptspuren und Logfiles. Genau in diesem Umfeld entstand auch der Name sslxy.

Der interne Hostname lautete ssl-server-xy. Für den praktischen Umgang brauchte es einen kurzen, brauchbaren Nutzernamen für FTP, CGI, Shell-Kontext und Logs. Daraus blieb sslxy hängen. Zuerst rein technisch. Später dann auch als sichtbarer Handle.

Das ist wichtig, weil damit klar wird: Der Name entstand nicht aus Selbstdarstellung, sondern aus Systemlogik. Erst Host, dann Dateiname, dann Logfile, dann Handle. Nicht umgekehrt.

• Shell-Account: Arbeitsumgebung für Dateioperationen, Rechte, Struktur und technische Routinen.
• FTP: praktische Upload-Schiene für HTML-Dateien und sonstige Inhalte.
• Logfiles: frühe technische Selbstkontrolle statt bloßem Bauchgefühl.
• Host-Name: ssl-server-xy als Ausgangspunkt des späteren Handles.

Genau diese Herkunft erklärt auch den Ton der späteren Arbeit. Wer aus Host, Datei, Prompt und Log kommt, denkt anders über Webseiten nach als jemand, der zuerst aus einer Oberfläche herausklickt.

Die Host- und Account-Seite dazu liegt ausführlicher auf shell-accounts-und-hosts.htm.

Document Root, Benutzerverzeichnis und Indexdatei

Der Webserver veröffentlicht nicht automatisch das gesamte Benutzerkonto. Er bildet eine URL auf ein konfiguriertes Dokumentverzeichnis ab. Auf Shell-Hosts konnte dies ein Benutzer-Unterverzeichnis wie public_html sein; Name und Aufbau waren jedoch hostabhängig.

Für eine Verzeichnis-URL suchte der Server häufig nach einer voreingestellten Indexdatei. Ob diese index.html, index.htm oder anders hieß, war Teil der Serverkonfiguration und durfte nicht erraten werden.

• Dokumentpfad: lokaler Hostpfad ist nicht identisch mit der öffentlichen URL.
• Indexdatei: vermeidet, dass der Dateiname in der URL stehen muss.
• Verzeichnislisting: konnte erlaubt, verboten oder durch Indexdatei ersetzt sein.
• CGI-Verzeichnis: dynamische Programme konnten in getrennten, ausführbaren Bereichen liegen.

Dateinamen, Groß-/Kleinschreibung und stabile Links

Auf typischen Unix-Hosts sind Bild.gif, bild.gif und BILD.GIF unterschiedliche Namen. Ein lokal tolerierter Unterschied konnte deshalb nach dem Upload als fehlende Ressource erscheinen.

• einheitliche Kleinschreibung: reduziert Tipp- und Plattformfehler.
• keine lokalen Laufwerksbuchstaben: C:\bilder\... ist keine Web-URL.
• keine Leerzeichenabhängigkeit: frühe Clients und Werkzeuge machten problematische Namen unnötig riskant.
• relative Pfade bewusst wählen: Verschieben eines Dokuments verändert den Bezugsort.
• bestehende URLs erhalten: spätere Umbenennung benötigt Weiterleitung oder dauerhafte Kompatibilitätsdatei.

Diese frühe Namensdisziplin ist bis heute relevant: Ein stabiler Pfad ist nicht nur Technik, sondern ein dauerhaftes Versprechen an Verweise, Lesezeichen und Archive.

Dateirechte: lesbar ist nicht dasselbe wie ausführbar

Auf einem Unix-Host bestimmen Eigentümer, Gruppe und übrige Benutzer, wer Dateien lesen, schreiben oder ausführen darf. Für statische Dateien und CGI-Programme gelten unterschiedliche Anforderungen.

Werte wie 644 für statische Dateien oder 755 für bestimmte Skripte sind typische Beispiele, aber keine universelle Vorgabe. Eigentümer, Servermodell und Sicherheitskonzept entscheiden.

Frühes HTML: nicht „schön“, sondern lesbar und abrufbar

HTML in den Jahren 1995 und 1996 war keine spätere Komfortzone. Man schrieb keine Komponenten, man „designte“ nicht im heutigen Sinn, und man baute auch keine schwergewichtigen Frontends. Man schrieb Markup. Absätze, Überschriften, Links, Listen, Bilder, Zeilenumbrüche, einfache Struktur. Alles, was darüber hinausging, musste erst einmal auf realen Browsern überhaupt funktionieren.

Genau deshalb war frühes HTML eher eine Frage der Disziplin als der Show. Ein Dokument musste logisch bleiben, auch wenn die Darstellung noch nicht perfekt war. Wer die Struktur nicht sauber baute, bekam das schnell zurück – in Form von kaputten Zeilen, verschobenen Elementen, schwer lesbaren Seiten oder unnötig großen Dateien.

Technisch war das eine Phase zwischen Spezifikation und Browserwirklichkeit. Man konnte sich nicht einfach darauf verlassen, dass jede korrekte Idee auch auf jedem System gleich aussah. Genau deshalb war die Grundhaltung so wichtig: erst Struktur, dann Wirkung.

„Die erste gute Webregel war nicht Design. Sie war: Die Datei muss sauber bleiben.“

HTML 2.0 als formaler gemeinsamer Stand Ende 1995

RFC 1866 definierte im November 1995 HTML 2.0 als SGML-Anwendung. Die Spezifikation fasste einen gemeinsamen Dokumentkern zusammen, obwohl Browser bereits zusätzliche, herstellerspezifische Elemente kannten.

Tabellen gehörten nicht zum Kern von HTML 2.0. Eine separate experimentelle Tabellenspezifikation erschien im Mai 1996. Praktische Browserunterstützung und Standardstatus waren deshalb nicht automatisch dasselbe.

URLs und relative Links: Adresse plus Kontext

RFC 1738 dokumentierte Ende 1994 die URL als kompakte Darstellung von Ort und Zugriffsverfahren. RFC 1808 ergänzte 1995 Regeln für relative URLs.

Relative Links erleichtern das Verschieben ganzer Verzeichnisbäume, können aber beim Verschieben einzelner Dateien brechen. Absolute URLs sind eindeutig, binden den Inhalt jedoch an Host und Pfad.

Bilder mussten ihren Übertragungsaufwand rechtfertigen

Auf langsamen Leitungen war jedes Bild eine bewusste Entscheidung. Abmessungen, Farbtiefe, Kompression und Anzahl der Requests wirkten direkt auf die wahrgenommene Seite.

• GIF: für palettenbasierte Grafiken, Logos und einfache transparente Flächen geeignet.
• JPEG: für fotografische Motive mit verlustbehafteter Kompression.
• ALT-Text: beschreibt die Funktion beziehungsweise Information, wenn das Bild nicht dargestellt wird.
• Abmessungen: bekannte Breite und Höhe helfen dem Browser, den Seitenraum früh einzuplanen.
• Dateiname und MIME-Typ: Erweiterung allein garantiert keine richtige Serverauslieferung.

„Bilder ausschalten“ war ein realer Browser- und Leitungskontext. Eine Seite musste deshalb auch ohne vollständig geladene Grafik navigierbar und verständlich bleiben.

MIME-Typ: Der Server sagt, welche Bytes er sendet

Der Browser benötigt nicht nur einen Dateinamen, sondern einen Medientyp in der HTTP-Antwort. HTML wird als text/html ausgeliefert; Bilder benötigen ihren jeweiligen Bildtyp.

Ein falscher Medientyp kann dazu führen, dass ein Browser Quelltext anzeigt, eine Datei herunterlädt oder ein Bild nicht interpretiert. Dateiendung, Serverkonfiguration und Antwortheader müssen zusammenpassen.

Upload, Pfade und die Wirklichkeit zwischen lokal und online

Eine Seite schrieb sich nicht einfach „ins Netz“. Zwischen lokaler Datei und erreichbarer Website lag ein realer technischer Weg: Verbindung aufbauen, auf den Host gehen, Dateien übertragen, an der richtigen Stelle ablegen, Pfade prüfen, Rechte im Blick behalten und danach kontrollieren, ob die Seite wirklich wie gedacht erreichbar war.

Gerade auf langsamen Leitungen war Upload keine Nebensache. Man überlegte genauer, welche Datei man wirklich ändern musste, was an Bildern nötig war, was man klein halten konnte und wie viele unnötige Korrekturschleifen man sich leisten wollte. Jede Nachbesserung bedeutete reale Übertragungszeit.

Genau dort lernte man auch sehr schnell, dass ein Fehler nicht „im Internet“ steckt, sondern meist an etwas Konkretem: falscher Pfad, falsch benannte Datei, unvollständige Übertragung, alter Link, versehentlich lokaler Denkfehler. Diese Art von Fehlern ist unerfreulich, aber lehrreich. Sie macht aus bloßem Ausprobieren echte technische Arbeit.

FTP ASCII und Binary: Textbehandlung kann Daten verändern

FTP unterscheidet Übertragungstypen. Im ASCII-Modus können Zeilenenden zwischen Systemdarstellungen umgesetzt werden. Im Image-/Binary-Modus werden die Bytes unverändert übertragen.

Umgekehrt konnten Textdateien nach binärer Übertragung formal unverändert, aber auf dem Zielsystem mit ungewohnten Zeilenenden erscheinen. Das ist ein Darstellungs- und Werkzeugproblem, nicht zwingend Datenverlust.

Klassisches FTP übertrug Zugangsdaten nicht vertraulich

Das klassische FTP-Protokoll verwendete getrennte Steuer- und Datenverbindungen. Benutzername und Passwort wurden über USER und PASS im Klartext übertragen. Das war bereits späterer Sicherheitsdokumentation zufolge ein abhörbares Risiko.

Diese historische Einordnung bedeutet nicht, dass damals auf dem konkreten Weg tatsächlich mitgelesen wurde. Sie erklärt aber, warum klassisches FTP heute nicht als vertraulicher Übertragungsweg gelten darf.

• FTP: klassisches Protokoll ohne eingebaute Transportverschlüsselung.
• FTPS: FTP mit TLS-Erweiterungen; nicht mit SFTP gleichsetzen.
• SFTP: Dateiübertragung über SSH, technisch ein anderes Protokoll.
• heutige Praxis: alte Zugangsdaten nicht weiterverwenden und historische Clients nicht ungeprüft ans Netz bringen.

Browserrealität 1995/96: weniger Vereinbarung, mehr Prüfung

Ein weiterer Unterschied zu späteren Jahren lag in der Browserseite. Frühe Webseiten liefen nicht in einer stabilisierten Alltagswelt, in der man sich auf ähnliche Interpretationen verlassen konnte. Was lokal oder in einem Client brauchbar aussah, konnte anderswo schon anders wirken. Genau deshalb war Kontrolle kein Luxus, sondern Teil der Arbeit.

Man musste stärker damit leben, dass es zwischen formalem HTML und tatsächlicher Darstellung Reibung gab. Nicht alles wurde gleich interpretiert, nicht alles sah auf jedem System sauber aus, und manche Darstellungen waren eher Ergebnis der damaligen Browserpraxis als einer reifen, ruhigen Standardlage.

• Links mussten eindeutig bleiben, auch wenn die Darstellung schlicht war.
• Bilder mussten sparsam eingesetzt werden, damit die Seite nicht unnötig schwer wurde.
• Texte mussten auch ohne optische Raffinesse noch funktionieren.
• Die Seite sollte nicht von einem einzelnen hübschen Effekt abhängen.

Gerade deshalb prägte sich früh eine Webhaltung aus, die später geblieben ist: lieber ruhig, logisch und lesbar bauen als sich von momentaner Wirkung blenden zu lassen. Nicht, weil Gestaltung unwichtig wäre, sondern weil Struktur zuerst trägt.

1995/96: Struktur, Browsererweiterungen und beginnende Stylesheets

HTML 2.0 bildete Ende 1995 einen konservativen gemeinsamen Kern. Gleichzeitig setzten Browser bereits Erweiterungen ein. Tabellen wurden im Mai 1996 in einem eigenen experimentellen RFC beschrieben. CSS1 folgte am 17. Dezember 1996 als W3C Recommendation.

Eine Seite aus dieser Phase sollte deshalb nicht rückwirkend so beschrieben werden, als hätten 1995 bereits heutige CSS- und Layoutbedingungen gegolten.

HTTP/1.0: nicht nur Dateiabruf, sondern Request und Response

RFC 1945 dokumentierte im Mai 1996 die bereits verwendete HTTP/1.0-Praxis. Ein Client sendet eine Request-Line und Header; der Server antwortet mit Status, Headern und gegebenenfalls einem Body.

Diese Trennung macht Fehlersuche präzise: Eine gültige TCP-Verbindung beweist noch keine gefundene Datei, und eine 200-Antwort beweist noch keine richtige Darstellung.

Erste CGI-Spuren, Logfiles und die nüchterne Selbstkontrolle

Zur frühen Webarbeit gehörte nicht nur statisches HTML. Relativ schnell wurde auch interessant, was über reine Dateien hinaus möglich war: CGI, Parameter, Ausgaben, erste dynamische Reaktionen, Logfiles und die grundsätzliche Frage, wie sich der Server tatsächlich verhält.

Gerade Logfiles waren hier entscheidend. Sie ersetzten Spekulation durch Spur. Statt nur zu glauben, dass etwas „irgendwie nicht ging“, konnte man sehen, welcher Aufruf ankam, ob ein Pfad stimmte, ob etwas ausgeliefert wurde, wo ein Fehler lag und welcher Teil der Kette überhaupt versagte.

Diese Logik war wahrscheinlich wichtiger als jede frühe „Dynamik“ an sich. Nicht weil CGI spektakulär gewesen wäre, sondern weil es den Blick schärfte: Ein Websystem ist nicht nur Oberfläche. Es hat Ein- und Ausgänge, Zustände, Fehlerbilder und technische Belege. Wer einmal so gearbeitet hat, behält diese Haltung später automatisch.

Die ausführliche technische Seite dazu steht auf cgi-und-logfiles.htm. Die Host-Umgebung darunter steht auf shell-accounts-und-hosts.htm.

Prüfung ohne heutige Devtools

Die damalige Fehlersuche war weniger komfortabel, aber nicht zwangsläufig unstrukturiert. Man reduzierte den Weg und prüfte sichtbare Zwischenstände.

1. lokale Datei öffnen: Grundsyntax und relative Ressourcen kontrollieren.
2. Dateigröße vergleichen: unvollständige Übertragung erkennen.
3. URL direkt abrufen: Navigation als zusätzliche Fehlerquelle ausschließen.
4. Quelltext anzeigen: tatsächlich ausgelieferte Version prüfen.
5. einfachen Browser verwenden: Struktur ohne besondere Erweiterungen testen.
6. Access- und Error-Log lesen: Request, Status und Serverfehler zuordnen.
7. minimalen Testfall bauen: komplexe Seite auf wenige Elemente reduzieren.

Ein Browsercache konnte einen alten Stand zeigen. Deshalb gehörten erzwungenes Neuladen, geänderte Test-URL oder direkter Vergleich der ausgelieferten Bytes zur praktischen Kontrolle.

Wartungsdateien und nachvollziehbare Änderungen

Auch ohne modernes Versionskontrollsystem ließ sich ein Webbestand nachvollziehbar pflegen. Entscheidend waren eindeutige Arbeitsstände und die Trennung zwischen Quelle und veröffentlichter Fassung.

• lokale Hauptkopie: nicht ausschließlich auf dem Host arbeiten.
• datierte Sicherung: vor größeren Änderungen einen Rückfallstand halten.
• Änderungsnotiz: Datum, Datei und Zweck kurz dokumentieren.
• Uploadliste: festhalten, welche Dateien tatsächlich übertragen wurden.
• Linkprüfung: nach Umbenennung interne und externe Verweise kontrollieren.
• Hostkopie zurücklesen: veröffentlichte Fassung nicht mit lokaler Annahme verwechseln.

Diese Arbeitsweise ist die historische Vorform dessen, was heute über Versionsverwaltung, Deployment-Manifest und automatisierte Tests kontrolliert werden kann.

1996: aus dem ersten Online-Schritt wird dauerhafte Webarbeit

Genau hier liegt der Unterschied zwischen 1995 und 1996. 1995 ist die reale erste Veröffentlichung. 1996 ist dann das Jahr, in dem daraus eine erkennbare, fortgesetzte Webarbeit wird. Nicht mehr nur eine frühe Online-Seite, sondern eine technische Linie mit Pflege, Überarbeitung, Struktur und Wiederholung.

Für mich ist deshalb 1996 der richtige Startpunkt der späteren Webbetreuung. Nicht, weil vorher nichts existiert hätte, sondern weil ab dort die Arbeit nicht mehr nur Versuch, sondern fortgesetzte Praxis ist. Genau deshalb wird die technische Webbetreuung sauber ab 1996 gerechnet.

Diese Unterscheidung ist wichtig, weil sie zwei Dinge gleichzeitig erlaubt: den ersten realen Schritt Ende 1995 korrekt zu benennen und die eigentliche dauerhafte Weblinie ab 1996 ebenso korrekt festzuhalten. Alles andere wäre bequemer, aber unsauber.

Genau diese Kontinuität ist der eigentliche Grund, warum die spätere Arbeit nie nach kurzfristigem Hype ausgesehen hat. Sie stammt nicht aus Präsentation, sondern aus früher Praxis mit echten Dateien, realen Hosts und nachvollziehbaren Fehlern.

Erhaltung früher Webseiten: mehr als einen Screenshot sichern

Ein Screenshot zeigt eine Darstellung, aber nicht die vollständige technische Website. Für eine belastbare Archivakte werden mehrere Ebenen zusammen erhalten.

Alte Dateien sollten möglichst unverändert mit Hashwerten gesichert werden. Eine modernisierte Lesefassung kann daneben existieren, muss aber als Bearbeitung vom Originalbestand getrennt bleiben.

Technische Referenzen

Die persönliche Chronologie stammt aus der eigenen Erinnerung und Datierung. Die allgemeinen Aussagen zu HTML, HTTP, URLs, FTP und CSS orientieren sich an zeitgenössischen beziehungsweise offiziellen Standards und Webhistorien.

RFC 3875 ist deutlich jünger als die Jahre 1995/96. Es wird hier nicht als damaliges Erscheinungsdatum ausgegeben, sondern als spätere formale Dokumentation der gewachsenen CGI-Schnittstelle.

Was aus diesen ersten Webjahren geblieben ist

Geblieben ist vor allem ein bestimmter Blick auf Webseiten. Nicht als Stimmung, nicht als Selbstdarstellung, nicht als Oberflächenprodukt, sondern als technische Struktur. Eine Seite muss auffindbar, lesbar, transportierbar, korrigierbar und später wieder verständlich sein. Genau diese Regeln sind in den Jahren 1995 und 1996 nicht theoretisch entstanden, sondern praktisch.

Dazu kommt etwas Zweites: die Abneigung gegen unnötigen Ballast. Wer frühe Webarbeit auf langsamen Leitungen, mit realen Pfaden, überschaubaren Browsern und direkter Datei-Kontrolle gelernt hat, entwickelt fast automatisch Misstrauen gegen alles, was ohne klaren Nutzen schwerer, lauter und unübersichtlicher wird.

In diesem Sinn sind die ersten Webseiten nicht bloß Vergangenheit. Sie erklären einen Teil der späteren Haltung: warum Code lesbar bleiben soll, warum Struktur vor Show kommt, warum Logik wichtiger ist als Marketing und warum technische Ruhe am Ende oft länger hält als jeder Zeitgeschmack.

„Die erste brauchbare Weblektion war einfach: Was online steht, muss technisch ehrlich gebaut sein.“

Die Host-Vorgeschichte dazu steht auf shell-accounts-und-hosts.htm. Die heutige Einordnung dieser Haltung liegt auf webmaster.htm. Die Hauptseite bleibt sslxy.

Querverweise im SSLXY-Archiv

• Zur SSLXY-Hauptseite
• Webmaster – heutige Einordnung der Arbeitsweise
• Shell-Accounts und Hosts
• CGI, Requests und Logfiles
• SSL und Zertifikate
• Server-Härtung
• Datensicherung und Wiederherstellung
• Modems, Mailboxen und Protokolle als Vorgeschichte