Webbol - servidor web estático minimalista escrito em COBOL

 (github.com/jmsdnns)
1 pontos por GN⁺ 2025-10-05 | 2 comentários | Compartilhar no WhatsApp
  • Servidor web estático minimalista escrito em COBOL, mostrando que é possível fazer programação de sistemas moderna com GnuCOBOL
  • Oferece recursos como servir arquivos estáticos do diretório atual, detecção automática de tipos MIME, tratamento de códigos de status HTTP (200/403/404/413), bloqueio de ataques de path traversal e exibição de logs de requisições
  • Por ser single-threaded, consegue processar apenas uma requisição por vez, com suporte a arquivos de até 64 KB
  • Funciona em ambientes compatíveis com POSIX (Linux/macOS/BSD) com GnuCOBOL instalado, podendo ser compilado com make e executado na porta 8080 com o comando ./webserver
  • Como exemplo de programa de rede escrito em COBOL, é um projeto que comprova que até uma linguagem legada pode implementar um servidor web moderno

Visão geral do projeto

  • Webbol é um servidor web estático minimalista desenvolvido com a linguagem COBOL e o compilador GnuCOBOL
  • O objetivo é servir arquivos estáticos simples e demonstrar a usabilidade moderna do COBOL

Principais recursos

  • Servir arquivos estáticos do diretório atual
  • Detecção automática de tipos MIME para formatos de arquivo comuns
  • Suporte aos códigos de status HTTP 200 (OK), 403 (Forbidden), 404 (Not Found) e 413 (Payload Too Large)
  • Prevenção contra ataques de path traversal (../ etc.)
  • Registro limpo de requisições, incluindo todos os cabeçalhos HTTP
  • Fornece index.html por padrão ao requisitar o caminho raiz

Requisitos do sistema

  • Necessita do compilador GnuCOBOL (cobc)
  • Necessita de um sistema operacional compatível com POSIX (Linux, macOS, BSD)
  • Necessita da ferramenta make

Exemplo de funcionamento e forma de acesso

Estrutura e composição dos arquivos

  • Makefile: configuração de build
  • README.md: arquivo de documentação explicativa
  • config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy: definições de estruturas de servidor, socket, HTTP e manipulação de arquivos
  • path-utils.cbl: validação e limpeza de caminhos
  • mime-types.cbl: lógica de identificação de tipos MIME
  • file-ops.cbl: operações de leitura de arquivos
  • http-handler.cbl: tratamento de requisições/respostas HTTP
  • webserver.cbl: programa principal do servidor

Tipos MIME suportados

  • HTML: text/html
  • CSS: text/css
  • JavaScript: application/javascript
  • JSON, XML, texto simples, PNG, JPEG, GIF, SVG, ICO, PDF etc.
  • É possível registrar tipos MIME adicionais no arquivo mime-types.cbl

Recursos de segurança

  • Prevenção de path traversal: bloqueia requisições que contenham a sequência ..
  • Restrição de acesso a diretórios: serve apenas arquivos do diretório atual e de seus subdiretórios
  • Manipulação segura de arquivos: validação e verificação do caminho antes do acesso ao sistema de arquivos

Limitações

  • Baseado em single thread: só consegue processar uma requisição por vez
  • Sem suporte a SSL/TLS (HTTPS)
  • Tamanho máximo de arquivo: 64 KB
  • Suporta apenas organização de arquivo sequencial por linhas (arquivos de texto)
  • Sem suporte a cache, compressão, range requests etc.

Leituras relacionadas

2 comentários

 
yangeok 2025-10-05

Até os comentários têm um visual bem curioso, kk
 
GN⁺ 2025-10-05
Comentários no Hacker News

  • Fiquei feliz em ver o modo de formato fixo do COBOL sendo usado de verdade
    O COBOL tem dois modos: formato livre (free mode) e formato fixo (fixed format mode)
    O formato fixo segue a herança da era dos cartões perfurados, separando o código por colunas específicas

    • colunas 1–6: número da linha

    • coluna 7: caractere indicador (por exemplo, * para comentário; dá para ver no código de exemplo)

    • colunas 8–11: marcador especial de division, às vezes ocupando mais do que isso (arquivo de exemplo)

    • colunas 12–72: instruções COBOL propriamente ditas

    • colunas 73–80: uso livre para comentários do programador etc.
      Como essa estrutura pesa para desenvolvedores e ferramentas de hoje, o modo de formato livre é o recomendado
      Mas o modo de formato fixo também tem um charme próprio, então, se você vai usar COBOL em 2025, eu recomendaria abraçar de vez a vibe antiga

    • As colunas 73–80 também eram usadas para marcar números de sequência, de modo que, se os cartões se espalhassem, uma máquina de classificação pudesse colocá-los em ordem novamente
      Para sentir como eram os cartões COBOL, dá para escolher cartões COBOL neste link
      Se quiser algo ainda mais retrô, você pode primeiro escrever o programa num formulário de codificação e depois fazer com que um assistente o perfure no keypunch (exemplo)

    • O Fortran antigo também usava uma estrutura de colunas fixas, só com disposição diferente
      O ponto em comum era deixar as colunas 73–80 livres para numeração de sequência de cartões e afins
      Nunca usei cartões de verdade, mas imagino que, como era fácil derrubá-los ou embaralhar a ordem, os números de sequência e a classificadora fossem extremamente úteis

    • Essa parte também me chamou atenção
      Mas achei engraçado que no Makefile eles estavam usando a opção -free do cobc

  • As pessoas dizem “use a melhor ferramenta para o trabalho”, mas, curiosamente, não escolhem COBOL para COmmon Business Oriented probLems

    • Isso também se aplica perfeitamente a MUMPS
      As pessoas ignoram o fato de que elas podem fazer uma escolha excelente

    • O ponto maior nem é que não escolham COBOL, mas sim que nem chegam a considerá-lo

    • Fico curioso sobre quando e por que as pessoas usam a expressão “a melhor ferramenta para o trabalho”

  • Nossa empresa tem mais de 40 ou 50 anos
    Ainda hoje, 90% das operações de negócio rodam em COBOL
    O pessoal da área trabalha em telas azuis feitas com RM/COBOL e RM/PANELS
    Até os anos 2010, ainda gerávamos HTML em COBOL, mas não recebíamos requisições HTTP diretamente
    Em vez disso, havia uma camada RPC atrás do Apache, que convertia requisições HTTP em CGI e as passava para o COBOL
    O programa COBOL enviava strings HTML pela interface CGIRPC, e o resultado aparecia no navegador como página web
    Ainda usamos isso com serviços XML e afins para complementar os webapps legados
    Honestamente, este projeto é uma experiência muito mais legal do que isso

  • Achei interessante ver que quase toda linha do código tem comentário
    Isso me faz repensar a premissa da frase “o código deve ser sua própria documentação”
    Essa ideia pressupõe que quem lê o código conhece a linguagem e que, em alguns casos, ele possa ser “autoexplicativo”
    Talvez quem é acostumado com COBOL diga que COBOL também pode ser suficientemente autoexplicativo, mas eu não tenho certeza

    • No commit d9a5e3e, dá para ver a mensagem “adiciona comentários para que pessoas curiosas possam entender o que cada linha faz”

    • Acho que essa ideia de que “o código é lido por alguém que conhece a linguagem” depende do contexto
      Num código escrito para aprender, sozinho ou para outras pessoas, é natural comentar o que cada linha faz
      Já em ambiente profissional, costuma ser uma escolha melhor organizar estruturalmente e deixar menos comentários, assumindo que a equipe conhece bem a linguagem

    • Já ouvi gente em banco dizer que código COBOL é naturalmente parecido com linguagem humana e, portanto, autoexplicativo; quase ri quando ouvi isso

  • Parece piada, mas fiquei realmente curioso e deixei uma pergunta
    Será que alguém aqui conhece bem as garantias relacionadas a segurança em COBOL?
    Por exemplo, queria saber se COBOL permite acesso fora dos limites da memória e qual é o risco de aparecer um buraco de segurança “por acidente”, como em C ou Rust

    • Em COBOL, acesso fora dos limites da memória normalmente gera erro em compiladores modernos e, se ainda assim compilar ou executar, você acaba com erro de runtime ou crash logo em seguida
      Dito isso, existe no COBOL o recurso de reference modification, que permite referenciar intencionalmente memória fora dos limites dos dados
      Não é totalmente seguro, mas como muita coisa é pega na compilação, a taxa de erros acidentais acaba sendo bem menor

    • Quando vi o http handler, pensei exatamente nisso também
      Parecia possível haver um buffer overrun caso faltasse um espaço entre o método e o path
      Não cheguei a testar, mas foi o tipo de preocupação que me veio à cabeça

  • Fiquei querendo entender melhor o que CALL "socket" faz
    CALL é chamada de subprograma, mas não sei onde "socket" está definido
    Já pensei antes em tentar fazer um webserver em COBOL, mas só vi na FAQ do GnuCOBOL que isso seria possível via CGI e não consegui avançar mais (veja a FAQ)
    Quero olhar este projeto mais a fundo
    Parece realmente muito interessante

    • "socket" pode ser uma chamada de system call

  • Houve uma época em que COBOL era usado como backend de sites de alguns órgãos do governo e de empresas
    Os sites daquela época eram fáceis de reconhecer por aquele HTML emitido em formato de largura fixa de 100 colunas

  • Eu achava que conseguia programar em qualquer linguagem, mas, vendo este projeto em COBOL, Assembly chega a parecer limpo e elegante em comparação
    Jms Dnns! Este projeto realmente abre a cabeça, um trabalho excelente

    • No meu primeiro emprego, eu dava suporte a sistemas de manufatura em COBOL e sistemas financeiros em Assembler
      Tendo lidado com pilhas de código-fonte de dezenas de centímetros nas duas linguagens, achava o lado COBOL muito mais fácil de organizar mentalmente
      Mas isso pode variar de pessoa para pessoa

  • Projeto muito legal
    Se alguém tiver dicas para começar com COBOL, eu adoraria ouvir

  • Agora estamos um passo mais perto da visão de COBOL on Cogs
    Dá para ver mais em coboloncogs.org