Webbol - Serveur web statique minimal écrit en COBOL

 (github.com/jmsdnns)
1 points par GN⁺ 2025-10-05 | 2 commentaires | Partager sur WhatsApp
  • Serveur web statique minimal écrit en COBOL, montrant qu’une programmation système moderne est possible avec GnuCOBOL
  • Offre des fonctionnalités comme la distribution de fichiers statiques du répertoire courant, la détection automatique du type MIME, la gestion des codes de statut HTTP (200/403/404/413), le blocage des attaques de traversée de chemin et l’affichage des logs de requêtes
  • Monothread, il ne peut traiter qu’une seule requête à la fois, avec une taille de fichier prise en charge jusqu’à 64 Ko
  • Fonctionne dans un environnement compatible POSIX (Linux/macOS/BSD) avec GnuCOBOL installé ; après compilation avec make, il peut être lancé sur le port 8080 avec la commande ./webserver
  • En tant qu’exemple de programme réseau écrit en COBOL, c’est un projet qui prouve qu’il est possible d’implémenter un serveur web moderne même avec un langage legacy

Aperçu du projet

  • Webbol est un serveur web statique minimal développé en langage COBOL avec le compilateur GnuCOBOL
  • Son objectif est de fournir simplement des fichiers statiques et de démontrer l’usage moderne de COBOL

Fonctionnalités principales

  • Serving de fichiers statiques du répertoire courant
  • Détection automatique du type MIME pour les formats de fichiers courants
  • Prise en charge des codes de statut HTTP 200 (OK), 403 (Forbidden), 404 (Not Found), 413 (Payload Too Large)
  • Protection contre les attaques de traversée de chemin (../, etc.)
  • Journalisation propre des requêtes avec en-têtes HTTP complets
  • index.html servi par défaut lors d’une requête sur le chemin racine

Configuration système requise

  • Compilateur GnuCOBOL (cobc) requis
  • Système d’exploitation compatible POSIX requis (Linux, macOS, BSD)
  • Outil make requis

Exemples de fonctionnement et mode d’accès

Structure et organisation des fichiers

  • Makefile : configuration de build
  • README.md : fichier d’explication
  • config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy : définitions des structures pour le serveur, les sockets, HTTP et le traitement des fichiers
  • path-utils.cbl : validation et nettoyage des chemins
  • mime-types.cbl : logique de détermination du type MIME
  • file-ops.cbl : opérations de lecture de fichiers
  • http-handler.cbl : traitement des requêtes/réponses HTTP
  • webserver.cbl : programme principal du serveur

Types MIME pris en charge

  • HTML : text/html
  • CSS : text/css
  • JavaScript : application/javascript
  • JSON, XML, texte brut, PNG, JPEG, GIF, SVG, ICO, PDF, etc.
  • Des types MIME supplémentaires peuvent être ajoutés dans le fichier mime-types.cbl

Fonctionnalités de sécurité

  • Prévention de la traversée de chemin : blocage des requêtes contenant la séquence ..
  • Restriction d’accès aux répertoires : seuls les fichiers du répertoire courant et de ses sous-répertoires sont servis
  • Gestion sécurisée des fichiers : validation et vérification du chemin avant l’accès au système de fichiers

Limitations

  • Basé sur un modèle monothread : une seule requête peut être traitée à la fois
  • Pas de prise en charge de SSL/TLS (HTTPS)
  • Taille maximale des fichiers : 64 Ko
  • Prise en charge uniquement des fichiers séquentiels ligne par ligne (fichiers texte)
  • Pas de prise en charge du cache, de la compression, des requêtes de plage, etc.

À lire aussi

2 commentaires

 
yangeok 2025-10-05

Même les commentaires ont une apparence vraiment étonnante,,
 
GN⁺ 2025-10-05
Commentaires sur Hacker News

  • Ça fait plaisir de voir le mode à format fixe de COBOL réellement utilisé
    COBOL a deux modes : le mode libre (free mode) et le mode à format fixe (fixed format mode)
    Le format fixe est un héritage de l’époque des cartes perforées, avec une structure définie par colonnes

    • Colonnes 1 à 6 : numéro de ligne

    • Colonne 7 : caractère indicateur (par ex. * pour un commentaire, visible dans cet exemple de code)

    • Colonnes 8 à 11 : marqueur spécial de division, parfois plus large (fichier d’exemple)

    • Colonnes 12 à 72 : véritables instructions COBOL

    • Colonnes 73 à 80 : usage libre, par exemple pour des notes du programmeur
      Comme cette structure est pénible pour les développeurs et les outils modernes, le mode libre est recommandé aujourd’hui
      Mais le mode à format fixe a aussi un charme bien à lui, donc si vous allez utiliser COBOL en 2025, autant profiter pleinement de l’ambiance rétro

    • Les colonnes 73 à 80 servaient aussi parfois à indiquer des numéros de séquence, afin de pouvoir remettre les cartes dans l’ordre avec une machine de tri si elles se dispersaient
      Pour ressentir un peu ce que c’était qu’une carte COBOL, on peut choisir des cartes COBOL sur ce lien
      Et pour une expérience encore plus rétro, on peut d’abord écrire le programme sur une feuille de codage, puis le faire perforer par un assistant (exemple)

    • L’ancien Fortran utilisait aussi une structure à colonnes fixes, avec une disposition différente
      Le point commun, c’est que les colonnes 73 à 80 étaient laissées libres pour les numéros de séquence servant au tri des cartes
      Je n’ai jamais utilisé de vraies cartes, mais comme il devait être facile d’en faire tomber ou d’en mélanger l’ordre, les numéros de séquence et les trieuses devaient être extrêmement utiles

    • Moi aussi, c’est ce point qui m’a marqué
      Mais j’ai trouvé amusant que le Makefile utilise l’option -free de cobc

  • Les gens disent qu’il faut « utiliser le meilleur outil pour le travail », mais ne choisissent pourtant jamais COBOL pour les COmmon Business Oriented probLems

    • Ça s’applique tout autant à MUMPS
      Les gens oublient qu’ils peuvent faire des choix audacieux

    • Ce n’est même pas qu’ils ne choisissent pas COBOL, c’est qu’ils ne le considèrent même pas

    • Je me demande quand et pourquoi on emploie exactement la formule « le meilleur outil pour le travail »

  • Mon entreprise existe depuis plus de 40 ou 50 ans
    Encore aujourd’hui, 90 % de nos opérations métier reposent sur COBOL
    Les équipes travaillent sur des écrans bleus construits avec RM/COBOL et RM/PANELS
    Jusqu’aux années 2010, on générait encore du HTML en COBOL, sans toutefois recevoir directement les requêtes HTTP
    À la place, on mettait une couche RPC derrière Apache, qui convertissait les requêtes HTTP en CGI pour les transmettre à COBOL
    Le programme COBOL envoyait une chaîne HTML via l’interface CGIRPC, et le résultat apparaissait comme page web dans le navigateur
    On utilise toujours cela, notamment avec des services XML, pour compléter les applications web existantes
    Honnêtement, ce projet est une expérience bien plus cool encore

  • C’est intéressant de voir que presque chaque ligne du code est commentée
    Ça fait réfléchir aux présupposés derrière l’idée que « le code devrait être auto-documenté »
    Cela suppose que la personne qui lit le code connaît le langage et que, selon les cas, l’auto-documentation est possible
    Ceux qui connaissent bien COBOL diraient sans doute que COBOL peut tout à fait être auto-documenté, mais je n’en suis pas sûr

    • Dans le commit Git d9a5e3e, on peut voir : « ajout de commentaires pour aider les curieux à comprendre ce que fait chaque ligne »

    • Je pense que l’idée selon laquelle « le code est lu par des gens qui connaissent le langage » dépend du contexte
      Quand on écrit du code pour apprendre, seul ou pour d’autres, il est naturel d’ajouter des commentaires expliquant chaque ligne
      En revanche, dans un cadre professionnel, en partant du principe que l’équipe maîtrise le langage, il peut être préférable de s’appuyer surtout sur la structure du code plutôt que sur des commentaires partout

    • J’ai déjà entendu des gens de la banque affirmer que le code COBOL était auto-documenté parce qu’il ressemblait au langage naturel, et j’ai failli éclater de rire

  • Ça ressemble à une blague, mais ça m’a vraiment rendu curieux, donc je pose la question
    Est-ce que quelqu’un s’y connaît bien en garanties de sécurité liées à COBOL ?
    Par exemple, COBOL permet-il les accès mémoire hors limites, et quel est le risque d’introduire « par erreur » des failles de sécurité, par rapport à C ou Rust ?

    • En COBOL, un accès mémoire hors limites provoquera une erreur avec un compilateur moderne, et si jamais ça compile ou s’exécute, on aboutira à une erreur d’exécution ou à un crash immédiat
      Cela dit, la fonctionnalité de modification de référence de COBOL permet de référencer intentionnellement de la mémoire en dehors des limites des données
      Ce n’est donc pas parfaitement sûr, mais beaucoup d’erreurs ou de mauvais usages sont détectés à la compilation, ce qui réduit tout de même fortement la probabilité d’erreurs accidentelles

    • En voyant le http handler, je me suis posé la même question
      Je me suis dit qu’il pouvait y avoir un risque de dépassement de tampon s’il manquait l’espace entre la méthode et le chemin
      Je ne l’ai pas testé moi-même, mais c’est le genre de question que ça m’a inspiré

  • J’aimerais bien en savoir plus sur ce que fait CALL "socket"
    CALL sert à appeler un sous-programme, mais je ne vois pas où "socket" est défini
    J’avais déjà envisagé d’écrire un serveur web en COBOL, mais je m’étais arrêté après avoir vu dans la FAQ de GnuCOBOL qu’on pouvait le faire via CGI (voir la FAQ)
    J’ai envie d’examiner ce projet plus en profondeur
    C’est vraiment fascinant

    • "socket" est peut-être un appel système

  • Il fut un temps où COBOL servait de backend pour certains sites web d’administrations et d’entreprises
    À l’époque, on reconnaissait facilement ces sites à leur HTML rendu dans un format à largeur fixe de 100 colonnes

  • Je pensais qu’on pouvait programmer dans n’importe quel langage, mais en voyant ce projet COBOL, j’en viens à trouver l’assembleur plus propre et plus élégant
    Jms Dnns ! C’est vraiment un superbe projet qui élargit les perspectives

    • À mon premier emploi, je maintenais des systèmes industriels en COBOL et des systèmes financiers en assembleur
      Pour avoir manipulé des piles de dizaines de centimètres de code source dans les deux langages, je trouvais COBOL bien plus facile à organiser mentalement
      Mais ça peut varier selon les personnes

  • Vraiment un superbe projet
    Je serais preneur de conseils pour débuter avec COBOL

  • Nous faisons maintenant un pas de plus vers la vision de COBOL on Cogs
    On peut en voir plus sur coboloncogs.org