Webbol - Servidor web estático minimalista escrito en COBOL

 (github.com/jmsdnns)
1 puntos por GN⁺ 2025-10-05 | 2 comentarios | Compartir por WhatsApp
  • Servidor web estático minimalista escrito en COBOL, que demuestra que es posible hacer programación de sistemas moderna usando GnuCOBOL
  • Ofrece funciones como servir archivos estáticos del directorio actual, detección automática de tipos MIME, manejo de códigos de estado HTTP (200/403/404/413), bloqueo de ataques de path traversal y registro de solicitudes
  • Es de un solo hilo, por lo que solo puede procesar una solicitud a la vez, y admite archivos de hasta 64KB
  • Funciona en entornos compatibles con POSIX (Linux/macOS/BSD) con GnuCOBOL instalado, y puede compilarse con make y ejecutarse en el puerto 8080 con el comando ./webserver
  • Como ejemplo de programa de red escrito en COBOL, es un proyecto que demuestra que también se puede implementar un servidor web moderno con un lenguaje legado

Descripción general del proyecto

  • Webbol es un servidor web estático minimalista desarrollado con el lenguaje COBOL y el compilador GnuCOBOL
  • Su objetivo es servir archivos estáticos simples y demostrar la utilidad moderna de COBOL

Funciones principales

  • Serving de archivos estáticos del directorio actual
  • Detección automática de tipos MIME para formatos de archivo comunes
  • Soporte para códigos de estado HTTP 200 (OK), 403 (Forbidden), 404 (Not Found), 413 (Payload Too Large)
  • Prevención de ataques de path traversal (../, etc.)
  • Registro limpio de solicitudes que incluye todos los headers HTTP
  • Entrega predeterminada de index.html cuando se solicita la ruta raíz

Requisitos del sistema

  • Se requiere el compilador GnuCOBOL (cobc)
  • Se requiere un sistema operativo compatible con POSIX (Linux, macOS, BSD)
  • Se requiere la herramienta make

Ejemplos de funcionamiento y acceso

Estructura y composición de archivos

  • Makefile: configuración de compilación
  • README.md: archivo de guía y explicación
  • config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy: definiciones de estructuras para servidor, sockets, HTTP y manejo de archivos
  • path-utils.cbl: validación y limpieza de rutas
  • mime-types.cbl: lógica para determinar tipos MIME
  • file-ops.cbl: operaciones de lectura de archivos
  • http-handler.cbl: manejo de solicitudes y respuestas HTTP
  • webserver.cbl: programa principal del servidor

Tipos MIME compatibles

  • HTML: text/html
  • CSS: text/css
  • JavaScript: application/javascript
  • JSON, XML, texto plano, PNG, JPEG, GIF, SVG, ICO, PDF, etc.
  • Es posible agregar tipos MIME adicionales en el archivo mime-types.cbl

Funciones de seguridad

  • Prevención de path traversal: bloquea solicitudes que contienen la secuencia ..
  • Restricción de acceso a directorios: solo sirve archivos del directorio actual y sus subdirectorios
  • Manejo seguro de archivos: validación y verificación de rutas antes de acceder al sistema de archivos

Limitaciones

  • Basado en un solo hilo: solo puede procesar una solicitud a la vez
  • Sin soporte para SSL/TLS (HTTPS)
  • Tamaño máximo de archivo: 64KB
  • Solo admite archivos secuenciales por línea (archivos de texto)
  • Sin soporte para caché, compresión ni solicitudes por rango

Lecturas relacionadas

2 comentarios

 
yangeok 2025-10-05

Hasta los comentarios tienen una forma bien curiosa, jaja.
 
GN⁺ 2025-10-05
Comentarios en Hacker News

  • Qué gusto ver que todavía se usa el modo de formato fijo de COBOL
    COBOL tiene dos modos: formato libre (free mode) y formato fijo (fixed format mode)
    El formato fijo sigue la herencia de la era de las tarjetas perforadas y se divide según columnas específicas

    • Columnas 1~6: número de línea

    • Columna 7: carácter indicador (por ejemplo, * para comentario; se puede ver en el código de ejemplo)

    • Columnas 8~11: marcadores especiales de division, a veces ocupan más que eso (archivo de ejemplo)

    • Columnas 12~72: instrucciones COBOL reales

    • Columnas 73~80: uso libre para comentarios del programador, etc.
      Como esta estructura hoy en día supone una carga para desarrolladores y herramientas, se recomienda el modo de formato libre
      Aun así, el modo de formato fijo tiene su encanto propio, así que si vas a usar COBOL en 2025, recomendaría disfrutar de verdad esa vibra retro

    • Las columnas 73~80 también se usaban para marcar números de secuencia y así poder reordenarlas con una máquina clasificadora si las tarjetas se caían al suelo
      Si quieres sentir cómo eran las tarjetas COBOL, puedes elegir tarjetas COBOL en este enlace
      Si quieres una sensación todavía más antigua, primero puedes escribir el programa en una hoja de codificación y luego hacer que un asistente lo pase a keypunch (ejemplo)

    • El Fortran antiguo también usaba una estructura de columnas fijas, aunque con una distribución distinta
      Lo que tenían en común era dejar libres las columnas 73~80 para números de secuencia y ordenamiento de tarjetas
      Yo nunca usé tarjetas reales, pero como debía de ser fácil dejarlas caer o desordenarlas, imagino que la numeración y la máquina clasificadora eran increíblemente útiles

    • Esa parte también me impresionó
      Pero me pareció curioso que en el Makefile usaran la opción -free de cobc

  • La gente dice “usa la mejor herramienta para el trabajo”, pero luego no elige COBOL para los COmmon Business Oriented probLems

    • Eso aplica igual para MUMPS
      La gente pasa por alto que puede tomar decisiones grandiosas

    • Más que no elegir COBOL, lo que pasa es que ni siquiera lo consideran

    • Me pregunto cuándo y por qué se usa la frase “la mejor herramienta para el trabajo”

  • Nuestra empresa tiene más de 40 o 50 años
    Incluso ahora, el 90% de la operación del negocio sigue basado en COBOL
    El personal operativo todavía trabaja en pantallas azules hechas con RM/COBOL y RM/PANELS
    Hasta la década de 2010 también generábamos HTML con COBOL, aunque no recibíamos solicitudes HTTP directamente
    En su lugar, teníamos una capa RPC detrás de Apache que convertía las solicitudes HTTP en CGI y se las pasaba a COBOL
    El programa COBOL enviaba cadenas HTML por la interfaz CGIRPC, y el resultado aparecía en el navegador como una página web
    Seguimos usándolo así con servicios XML y similares para complementar las webapps existentes
    Sinceramente, este proyecto es una experiencia mucho más genial que eso

  • Me parece interesante ver que casi todas las líneas del código tienen comentarios
    Hace replantearse la premisa detrás de la frase “el código debe documentarse solo”
    Eso parte de la base de que quien lee el código conoce el lenguaje y de que, según el caso, sea posible que sea “autodocumentado”
    Quizá quienes están acostumbrados a COBOL dirían que COBOL también puede ser suficientemente autodocumentado, pero yo no lo tengo tan claro

    • En el commit d9a5e3e se puede ver que “se agregaron comentarios para que la gente curiosa entienda qué hace cada línea”

    • Creo que la idea de que “el código lo lee alguien que conoce el lenguaje” depende del contexto
      Si escribes código mientras aprendes, ya sea para ti o para otros, me parece natural comentar qué hace cada línea
      En cambio, en un entorno profesional, asumir que el equipo conoce bien el lenguaje y gestionarlo de forma estructurada, por lo general sin tantos comentarios, puede ser una mejor opción

    • En bancos he visto gente decir que el código COBOL ya de por sí parece lenguaje natural y que por eso es autodocumentado; casi me daba risa escucharlo

  • Suena a broma, pero de verdad me surgió la duda y quise preguntar
    Me pregunto si alguien conoce bien las garantías relacionadas con seguridad en COBOL
    Por ejemplo, quisiera saber si COBOL permite accesos fuera de rango en memoria y qué tanto riesgo hay de que aparezcan agujeros de seguridad “por accidente”, como en C o Rust

    • En COBOL, un acceso fuera de rango en memoria normalmente hace que un compilador moderno marque error y, si llega a compilarse o ejecutarse, termine en error de runtime o en un crash inmediato
      Aun así, existe la posibilidad de referenciar memoria fuera de los límites de los datos de forma intencional mediante la función de reference modification de COBOL
      No es totalmente seguro, pero como en compilación se detectan muchos errores o malos usos, la tasa de fallos accidentales sí baja bastante

    • Al ver el http handler, yo también me pregunté lo mismo
      Parecía que si faltaba el espacio entre el método y la ruta podía haber un posible buffer overrun
      No lo probé directamente, pero fue una de esas preocupaciones que me surgieron

  • Me dan ganas de entender mejor qué hace CALL "socket"
    CALL es una llamada a subprograma, pero no veo dónde está definido "socket"
    Hace tiempo también pensé en intentar hacer un servidor web en COBOL, pero en el FAQ de GnuCOBOL solo vi que era posible con CGI y no avancé más (ver FAQ)
    Quiero mirar este proyecto más a fondo
    De verdad se siente muy interesante

    • "socket" podría ser una llamada al sistema

  • Hubo una época en que COBOL se usaba como backend de sitios web de algunas agencias gubernamentales y empresas
    Los sitios de esa época se reconocían fácilmente por esa forma tan particular de generar HTML en un formato de ancho fijo de 100 columnas

  • Yo pensaba que podía programar en cualquier lenguaje, pero viendo este proyecto en COBOL hasta Assembly me parece más limpio y elegante
    ¡Jms Dnns! Este proyecto de verdad expande la manera de pensar

    • En mi primer trabajo me tocó dar soporte a sistemas de manufactura en COBOL y a sistemas financieros en Assembler
      Habiendo trabajado con pilas de código fuente de varias decenas de centímetros en ambos lenguajes, COBOL me resultaba mucho más fácil de ordenar en la cabeza
      Supongo que depende de cada quien

  • Es un proyecto realmente genial
    Si tienen consejos para empezar con COBOL, me gustaría escucharlos

  • Ahora estamos un paso más cerca de la visión de COBOL on Cogs
    Puedes ver más en coboloncogs.org