Webbol - Minimaler statischer Webserver, geschrieben in COBOL

 (github.com/jmsdnns)
1 Punkte von GN⁺ 2025-10-05 | 2 Kommentare | Auf WhatsApp teilen
  • Ein minimaler statischer Webserver, geschrieben in COBOL, der zeigt, dass mit GnuCOBOL moderne Systemprogrammierung möglich ist
  • Bietet Funktionen wie Bereitstellung statischer Dateien aus dem aktuellen Verzeichnis, automatische MIME-Typ-Erkennung, Verarbeitung von HTTP-Statuscodes (200/403/404/413), Blockierung von Path-Traversal-Angriffen und Ausgabe von Request-Logs
  • Single-Threaded und kann daher immer nur eine Anfrage gleichzeitig verarbeiten; unterstützt Dateigrößen bis maximal 64 KB
  • Läuft in POSIX-kompatiblen Umgebungen (Linux/macOS/BSD) mit installiertem GnuCOBOL; nach dem Kompilieren mit make kann es mit dem Befehl ./webserver auf Port 8080 gestartet werden
  • Ein Projekt als Beispiel für ein in COBOL geschriebenes Netzwerkprogramm, das belegt, dass sich auch mit einer Legacy-Sprache ein moderner Webserver implementieren lässt

Projektüberblick

  • Webbol ist ein minimaler statischer Webserver, entwickelt mit der COBOL-Sprache und dem GnuCOBOL-Compiler
  • Ziel ist die einfache Auslieferung statischer Dateien und der Nachweis der modernen Einsetzbarkeit von COBOL

Hauptfunktionen

  • Auslieferung statischer Dateien aus dem aktuellen Verzeichnis
  • Automatische MIME-Typ-Erkennung für gängige Dateiformate
  • Unterstützung für die HTTP-Statuscodes 200 (OK), 403 (Forbidden), 404 (Not Found), 413 (Payload Too Large)
  • Schutz vor Path-Traversal-Angriffen (../ usw.)
  • Saubere Request-Logs einschließlich vollständiger HTTP-Header
  • Standardmäßige Bereitstellung von index.html bei Anfragen an den Root-Pfad

Systemanforderungen

  • GnuCOBOL-Compiler (cobc) erforderlich
  • POSIX-kompatibles Betriebssystem erforderlich (Linux, macOS, BSD)
  • make erforderlich

Beispiel für die Funktionsweise und Zugriff

Struktur und Dateiaufbau

  • Makefile: Build-Konfiguration
  • README.md: Datei mit Erläuterungen
  • config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy: Definitionen für Server-, Socket-, HTTP- und Dateiverarbeitungsstrukturen
  • path-utils.cbl: Validierung und Bereinigung von Pfaden
  • mime-types.cbl: Logik zur Bestimmung von MIME-Typen
  • file-ops.cbl: Datei-Lesevorgänge
  • http-handler.cbl: Verarbeitung von HTTP-Anfragen und -Antworten
  • webserver.cbl: Hauptprogramm des Servers

Unterstützte MIME-Typen

  • HTML: text/html
  • CSS: text/css
  • JavaScript: application/javascript
  • JSON, XML, Plain Text, PNG, JPEG, GIF, SVG, ICO, PDF usw.
  • Weitere MIME-Typen können in der Datei mime-types.cbl ergänzt werden

Sicherheitsfunktionen

  • Schutz vor Path Traversal: Blockiert Anfragen, die die Sequenz .. enthalten
  • Einschränkung des Verzeichniszugriffs: Es werden nur Dateien im aktuellen Verzeichnis und dessen Unterverzeichnissen bereitgestellt
  • Sicheres Datei-Handling: Pfadprüfung und Validierung vor dem Zugriff auf das Dateisystem

Einschränkungen

  • Single-Threaded: Kann immer nur eine Anfrage gleichzeitig verarbeiten
  • Keine Unterstützung für SSL/TLS (HTTPS)
  • Maximale Dateigröße: 64 KB
  • Unterstützt nur zeilensequentielle Dateiformate (Textdateien)
  • Kein Support für Cache, Komprimierung, Range Requests usw.

Verwandte Beiträge

2 Kommentare

 
yangeok 2025-10-05

Sogar die Kommentare sehen irgendwie ziemlich faszinierend aus,,
 
GN⁺ 2025-10-05
Hacker-News-Kommentare

  • Es ist schön zu sehen, dass der Fixed-Format-Modus von COBOL tatsächlich noch verwendet wird
    COBOL hat zwei Modi: Free Format (free mode) und Fixed Format (fixed format mode)
    Das Fixed Format folgt als Erbe aus der Lochkarten-Ära einer festen Aufteilung nach Spalten

    • Spalten 1–6: Zeilennummern

    • Spalte 7: Indikatorzeichen (z. B. * für Kommentare, siehe im Beispielcode)

    • Spalten 8–11: spezielle Division-Marker, manchmal auch mehr als das (Beispieldatei)

    • Spalten 12–72: die eigentlichen COBOL-Anweisungen

    • Spalten 73–80: frei nutzbar, z. B. für Programmer-Kommentare
      Diese Struktur ist für heutige Entwickler und Tools eher eine Belastung, daher wird der Free-Format-Modus empfohlen
      Aber der Fixed-Format-Modus hat seinen ganz eigenen Charme, also wenn man 2025 schon COBOL benutzt, sollte man das echte Retro-Gefühl auch auskosten

    • Die Spalten 73–80 wurden auch für Sequenznummern genutzt, damit Karten nach dem Herunterfallen mit einer Sortiermaschine wieder in die richtige Reihenfolge gebracht werden konnten
      Wer ein Gefühl für COBOL-Lochkarten bekommen will, kann unter diesem Link COBOL-Karten auswählen
      Wenn man noch mehr altes Flair will, kann man das Programm zuerst auf einem Coding Sheet schreiben und es dann von einem Assistenten lochen lassen (Beispiel)

    • Auch altes Fortran nutzte ein festes Spaltenschema, nur mit anderer Aufteilung
      Gemeinsam war, dass die Spalten 73–80 für Sequenznummern zur Kartensortierung freigehalten wurden
      Ich habe nie mit echten Karten gearbeitet, aber weil man sie leicht fallen lassen oder vertauschen konnte, waren Reihenfolgenummern und Sortiermaschinen vermutlich extrem nützlich

    • Das ist mir auch aufgefallen
      Lustig fand ich allerdings, dass im Makefile die Option -free von cobc verwendet wird

  • Die Leute sagen immer, man solle „das beste Werkzeug für die Aufgabe“ verwenden, wählen aber ausgerechnet für COmmon Business Oriented probLems nicht COBOL

    • Das gilt genauso für MUMPS
      Die Leute übersehen, dass sie überhaupt eine außergewöhnliche Wahl treffen könnten

    • Es geht weniger darum, dass COBOL nicht ausgewählt wird, sondern eher darum, dass es gar nicht erst in Betracht gezogen wird

    • Ich frage mich, wann und warum Leute überhaupt den Satz „das beste Werkzeug für die Aufgabe“ benutzen

  • Unsere Firma ist über 40 bis 50 Jahre alt
    Noch heute laufen 90 % des Geschäftsbetriebs auf COBOL
    Die Fachanwender arbeiten auf Blue-Screens, die mit RM/COBOL und RM/PANELS gebaut wurden
    Bis in die 2010er Jahre wurde auch HTML mit COBOL erzeugt, aber HTTP-Anfragen wurden nicht direkt entgegengenommen
    Stattdessen gab es hinter Apache eine RPC-Schicht, die HTTP-Anfragen in CGI umwandelte und an COBOL weitergab
    Das COBOL-Programm schickte HTML-Strings über die CGIRPC-Schnittstelle, und das Ergebnis erschien als Webseite im Browser
    Das wird noch immer etwa für XML-Services genutzt und ergänzt die bestehenden Web-Apps
    Ehrlich gesagt ist dieses Projekt aber eine deutlich coolere Erfahrung

  • Interessant zu sehen, dass fast jede Codezeile kommentiert ist
    Das bringt mich dazu, die Annahme hinter „Code sollte selbstdokumentierend sein“ noch einmal zu überdenken
    Dahinter steckt die Voraussetzung, dass der Leser die Sprache kennt und dass „selbstdokumentierend“ in manchen Fällen überhaupt möglich ist
    Wer mit COBOL vertraut ist, würde vermutlich sagen, dass auch COBOL durchaus selbstdokumentierend sein kann, aber ich bin mir da nicht sicher

    • Im Git-Commit d9a5e3e steht, dass Kommentare hinzugefügt wurden, damit Neugierige verstehen können, was jede Zeile macht

    • Ich denke, die Aussage „Code wird von Leuten gelesen, die die Sprache kennen“ hängt stark vom Kontext ab
      Wenn man allein oder zum Lernen für andere schreibt, ist es ganz natürlich, jede Zeile zu kommentieren
      In professionellen Umgebungen kann es dagegen sinnvoller sein, strukturiert und meist ohne Kommentare zu arbeiten, weil man davon ausgeht, dass das Team die Sprache gut beherrscht

    • Ich habe auch schon Leute in Banken sagen hören, COBOL sei ursprünglich wie natürliche Sprache und deshalb selbstdokumentierend, und ich musste mir dabei fast das Lachen verkneifen

  • Das klingt vielleicht wie ein Witz, aber ich frage aus echtem Interesse
    Kennt sich jemand gut mit den sicherheitsbezogenen Garantien von COBOL aus?
    Ich würde zum Beispiel gern wissen, ob COBOL Zugriffe außerhalb von Speichergrenzen erlaubt und wie groß das Risiko ist, durch ein „Versehen“ Sicherheitslücken zu erzeugen, wie in C oder Rust

    • Zugriffe außerhalb von Speichergrenzen führen in COBOL mit modernen Compilern zu einem Fehler, und falls etwas doch kompiliert oder läuft, endet es meist in einem Laufzeitfehler oder einem sofortigen Absturz
      Allerdings gibt es in COBOL die Funktion reference modification, mit der man absichtlich Speicher außerhalb von Datengrenzen referenzieren kann
      Ganz sicher ist es also nicht, aber viele Fehler und Fehlbenutzungen werden schon beim Kompilieren erkannt, wodurch versehentliche Fehler wohl deutlich seltener sind

    • Beim Ansehen des HTTP-Handlers habe ich mich dasselbe gefragt
      Wenn zwischen Methode und Pfad ein Leerzeichen fehlt, schien mir ein Buffer Overflow möglich
      Ich habe es nicht selbst ausprobiert, aber solche Überlegungen kamen mir dabei

  • Ich würde gern mehr darüber wissen, was CALL "socket" eigentlich macht
    CALL ist ein Unterprogrammaufruf, aber ich verstehe nicht, wo "socket" definiert ist
    Ich hatte früher auch schon einmal darüber nachgedacht, einen COBOL-Webserver zu bauen, bin aber nicht weitergekommen, nachdem ich in den GnuCOBOL-FAQ nur gelesen hatte, dass es per CGI möglich ist (FAQ)
    Ich möchte mir dieses Projekt genauer ansehen
    Es wirkt wirklich interessant

    • socket könnte ein Systemaufruf sein

  • Es gab eine Zeit, in der COBOL als Backend für einige Regierungs- und Unternehmenswebsites verwendet wurde
    Solche Seiten konnte man damals leicht an ihrer charakteristischen HTML-Ausgabe im festen 100-Spalten-Format erkennen

  • Ich dachte immer, ich könnte in jeder Sprache programmieren, aber dieses COBOL-Projekt lässt sogar Assembly sauber und elegant wirken
    Jms Dnns! Dieses Projekt ist wirklich großartig und erweitert den Horizont

    • In meinem ersten Job betreute ich Fertigungssysteme in COBOL und Finanzsysteme in Assembler
      Nachdem ich Quellcode-Stapel von mehreren Dutzend Zentimetern in beiden Sprachen durchgearbeitet habe, fiel es mir bei COBOL deutlich leichter, den Überblick im Kopf zu behalten
      Aber das ist sicher von Person zu Person verschieden

  • Wirklich ein großartiges Projekt
    Ich würde gern Tipps hören, wie man am besten in COBOL einsteigt

  • Damit sind wir der Vision von COBOL on Cogs wieder einen Schritt näher
    Mehr dazu auf coboloncogs.org