erste-webseiten-1995-1996

Archivchronologie und allgemeine Webgeschichte getrennt halten

Die Seite verbindet eine überlieferte Projektchronologie mit der technischen Entwicklung des Webs. Die Datierungen des Archivs beziehen sich auf die hier dokumentierte Webarbeit; RFC- und W3C-Daten beschreiben dagegen den allgemeinen Standardisierungsstand der jeweiligen Zeit.

Was 1994/95 daran technisch neu war

Frühe Webseiten waren nicht einfach „der Anfang des Internets“. Vor der eigenen Webphase gab es längst digitale Praxis mit Mailboxen, Bildschirmtext, Modems, Terminalprogrammen, Dateiaustausch, Hosts und technischer Kommunikation über langsame Leitungen. Neu war vielmehr die öffentliche Bereitstellung eines Dokuments über das World Wide Web: Eine Datei konnte über eine URL direkt von einem Webserver abgerufen und in einem Browser dargestellt werden.

Damit änderte sich der technische Rahmen. Die Datei lag auf einem Host, musste übertragen, korrekt abgelegt, sinnvoll benannt und so geschrieben werden, dass die damaligen Browser sie verarbeiten konnten. Was heute selbstverständlich erscheint, war damals eine eigene Veröffentlichungskette mit mehreren voneinander abhängigen Ebenen.

Moderne Browser-DevTools, Paketmanager, Frameworks und automatisierte Build-Prozesse standen in dieser Form nicht zur Verfügung. HTML-Dateien wurden direkt bearbeitet, übertragen, aufgerufen und anschließend anhand der sichtbaren Ausgabe sowie der Serverreaktion korrigiert. Fehler waren dadurch weniger abstrahiert und oft unmittelbar auf Datei-, Pfad- oder Protokollebene sichtbar.

„Neu war nicht die digitale Kommunikation an sich, sondern das öffentlich abrufbare Webdokument.“

1995: die erste dokumentierte Veröffentlichung

Für die Chronologie ist die zeitliche Trennung entscheidend. Erste eigene Webseiten entstanden bereits 1994/95. Öffentlich erreichbar wurde die erste dokumentierte eigene Webveröffentlichung – die Website des Goldenen Ochsen – am 30.12.1995. Dieses Datum bezeichnet den archivierten Veröffentlichungspunkt und wird nicht mit dem Beginn der späteren fortgesetzten Webarbeit gleichgesetzt.

Zwischen einer lokal funktionierenden HTML-Datei und einer tatsächlich veröffentlichten Website lag damals eine deutlich sichtbare technische Strecke. Erst wenn die Datei auf dem Host lag, über die reale Verbindung erreichbar war, unter der vorgesehenen URL antwortete und im Browser brauchbar dargestellt wurde, war die Veröffentlichung vollständig.

Genau diese letzte Stufe war praktisch entscheidend: Leitung, Host, Transfer, Zielpfad, Dateirechte, HTTP-Abruf und Browserdarstellung mussten zusammenpassen. Die erste Veröffentlichung war deshalb nicht nur ein Schreibvorgang, sondern ein erfolgreicher Durchlauf der gesamten technischen Kette.

Damit bildet Ende 1995 die Schwelle zur öffentlichen Webveröffentlichung. Die kontinuierliche technische Linie wird im Archiv ab 1996 geführt.

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 eine zentrale technische Arbeitsumgebung. Dort lagen Benutzerdateien und Pfade; dort wurden Rechte, Uploads, Skripte und Logdateien kontrolliert. In diesem Umfeld entstand auch die technische Kennung sslxy.

Der überlieferte Host-Kontext lautete ssl-server-xy. Für Login, FTP, CGI, Shell-Kontext und Logs war eine kurze Kennung praktischer. Aus dieser Verkürzung blieb sslxy erhalten. Erst später wurde die Kennung außerhalb des unmittelbaren Systemkontexts sichtbar und schließlich zum Namen des heutigen Archivs.

Die Herkunft ist damit technisch und nicht biografisch oder markenbezogen: zuerst Host- und Accountkontext, daraus eine kurze Kennung, später die Archivbezeichnung.

• Shell-Account: Arbeitsumgebung für Dateioperationen, Rechte, Struktur und technische Routinen.
• FTP: praktische Upload-Methode für HTML-Dateien und weitere Ressourcen.
• Logdateien: direkte technische Kontrolle von Abrufen und Fehlern.
• Host-Kontext: ssl-server-xy als überlieferter Ausgangspunkt der späteren Kennung sslxy.

Diese Herkunft erklärt zugleich, warum im Archiv Dateistruktur, Pfade, Serverantworten und Wartbarkeit einen hohen Stellenwert besitzen: Die frühe Webpraxis begann nicht in einer visuellen Oberfläche, sondern unmittelbar an Dateien, Accounts und Serverreaktionen.

Die Host- und Accountumgebung wird ausführlicher auf shell-accounts-und-hosts.htm behandelt.

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: Struktur, Lesbarkeit und Browserpraxis

HTML der Jahre 1995 und 1996 war wesentlich unmittelbarer als heutige Frontend-Entwicklung. Komponentenmodelle, moderne Build-Ketten und große clientseitige Frameworks gehörten nicht zur damaligen Alltagspraxis. Geschrieben wurde Markup: Überschriften, Absätze, Links, Listen, Bilder, Formulare und weitere damals verfügbare Strukturelemente.

Entscheidend war eine klare Dokumentstruktur. Browser interpretierten nicht jede Erweiterung identisch, Übertragungsraten waren begrenzt und unnötig große Dateien fielen stärker ins Gewicht. Ein verständliches Dokument musste deshalb auch ohne aufwendige Präsentation funktionieren.

Die Jahre 1995/96 lagen zwischen formaler Spezifikation und schnell fortschreitender Browserpraxis. Nicht jede verbreitete Darstellung war bereits Bestandteil derselben Spezifikation. Gerade deshalb blieben einfache, nachvollziehbare Strukturen besonders wertvoll.

„Struktur blieb wichtiger als ein Effekt, der nur in einem einzelnen Browser funktionierte.“

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: mehr Unterschiede, mehr direkte Prüfung

Frühe Webseiten liefen nicht in der heutigen weitgehend standardisierten Browserumgebung. Was in einem Browser brauchbar aussah, konnte in einem anderen sichtbar abweichen. Deshalb gehörte die praktische Prüfung in mehreren Umgebungen zur Webarbeit.

Zwischen formalem HTML und realer Darstellung bestand Reibung. Browser unterstützten unterschiedliche Erweiterungen, interpretierten Markup nicht immer identisch und entwickelten sich schnell weiter. Ein Teil der damaligen Gestaltung war deshalb eher Browserpraxis als Ausdruck eines bereits konsolidierten Standards.

• Links mussten eindeutig und ohne grafische Effekte verständlich bleiben.
• Bilder wurden wegen Bandbreite und Ladezeit bewusst eingesetzt.
• Texte mussten auch bei schlichter Darstellung lesbar bleiben.
• Wichtige Funktionen durften nicht von einer einzelnen Browserbesonderheit abhängen.

Aus dieser Situation ergibt sich eine bis heute sinnvolle Regel: Gestaltung darf die Struktur unterstützen, sollte sie aber nicht ersetzen.

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, Logdateien 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, Logdateien und die grundsätzliche Frage, wie sich der Server tatsächlich verhält.

Gerade Logdateien 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 der frühen Webphase wird fortgesetzte Webarbeit

Die Archivchronologie unterscheidet drei Schritte: 1994/95 stehen für die ersten eigenen Webseiten, der 30.12.1995 für die erste dokumentierte öffentliche Veröffentlichung und 1996 für den Beginn einer fortgesetzten Webpraxis mit Pflege, Überarbeitung, Struktur und wiederholter Veröffentlichung.

Deshalb wird die langfristige technische Webarbeit im Archiv weiterhin ab 1996 gerechnet. Das widerspricht weder den ersten Webseiten 1994/95 noch dem dokumentierten Online-Schritt Ende 1995, sondern trennt Entstehung, Erstveröffentlichung und kontinuierliche Pflege sauber voneinander.

Diese zeitliche Trennung verhindert eine nachträgliche Vereinfachung der Entwicklung. Die erste Veröffentlichung und die spätere dauerhafte Weblinie bleiben als zwei eigenständige, aufeinanderfolgende Schritte erkennbar.

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.

Was aus den ersten Webjahren technisch geblieben ist

Die frühen Webjahre zeigen eine Arbeitsweise, bei der Website-Struktur und Serverrealität unmittelbar zusammengehörten. Eine Seite musste auffindbar, lesbar, übertragbar, korrigierbar und später wieder verständlich sein. Diese Eigenschaften entstanden nicht aus einem späteren Leitbild, sondern aus den praktischen Anforderungen des damaligen Betriebs.

Begrenzte Bandbreite, direkte Datei-Kontrolle und klar sichtbare Fehlerwege förderten außerdem einen sparsamen Umgang mit technischer Komplexität. Zusätzliche Elemente mussten ihren Nutzen rechtfertigen, weil jede Datei, jedes Bild und jeder Fehler unmittelbar spürbarer war als in vielen heutigen abstrahierten Umgebungen.

Für das heutige Archiv ergibt sich daraus keine Forderung, Technik auf dem Stand von 1996 einzufrieren. Relevant bleibt vielmehr das Prinzip: nachvollziehbare Strukturen, lesbarer Code, kontrollierte Abhängigkeiten und Technik, die einer konkreten Aufgabe dient.

„Was online steht, sollte auch Jahre später noch technisch nachvollziehbar sein.“

Die Host-Vorgeschichte wird auf shell-accounts-und-hosts.htm vertieft. Die Webpraxis von 1996 steht auf webdev-1996.htm. Die langfristige Einordnung der Website-Pflege behandelt webmaster.htm.

Querverweise im SSLXY-Archiv

• Zur Startseite von sslxy.de
• Erhaltener Goldener-Ochsen-Webseitenstand von 1996
• Webentwicklung 1996 – Shell, SSLeay, HTML, HTTP und CGI
• Webmaster-Arbeit seit 1996
• Shell-Accounts und Hosts
• CGI, Requests und Logdateien
• SSL und Zertifikate
• Server-Härtung
• Datensicherung und Wiederherstellung
• Modems, Mailboxen und Protokolle als Vorgeschichte