- COBOLで書かれたミニマルな静的Webサーバーで、GnuCOBOLを使って現代的なシステムプログラミングが可能であることを示す
- 現在のディレクトリの静的ファイル配信、MIMEタイプの自動判定、HTTPステータスコード処理（200/403/404/413）、パストラバーサル攻撃の防止、リクエストログ出力 などの機能を提供
- シングルスレッドで、一度に1件のリクエストしか処理できず、ファイルサイズは最大64KBまで対応
- GnuCOBOLがインストールされた POSIX互換環境（Linux/macOS/BSD） で動作し、
makeでコンパイル後、./webserver コマンドで8080ポート上で実行可能
- COBOL言語で書かれたネットワークプログラムの例として、レガシー言語でもモダンなWebサーバーを実装できることを証明するプロジェクト
プロジェクト概要
- Webbolは、COBOL言語とGnuCOBOLコンパイラを使って開発されたミニマルな静的Webサーバー
- 目的は、シンプルな静的ファイル配信とCOBOLの現代的な実用性を示すこと
主な機能
- 現在のディレクトリの 静的ファイル配信
- 一般的なファイル形式に対する 自動MIMEタイプ判定
- HTTPステータスコード 200（OK）、403（Forbidden）、404（Not Found）、413（Payload Too Large）をサポート
- パス移動攻撃（../ など）の防止
- HTTPヘッダー全体を含む クリーンなリクエストログ記録
- ルートパスへのリクエスト時に index.html をデフォルトで提供
システム要件
- GnuCOBOL（cobc）コンパイラ が必要
- POSIX互換OSが必要（Linux、macOS、BSD）
- makeツールが必要
動作例とアクセス方法
構造とファイル構成
- Makefile: ビルド設定
- README.md: 説明用ファイル
- config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy: サーバー、ソケット、HTTP、ファイル処理の構造定義
- path-utils.cbl: パス検証と正規化
- mime-types.cbl: MIMEタイプ判定ロジック
- file-ops.cbl: ファイル読み取り処理
- http-handler.cbl: HTTPリクエスト/レスポンス処理
- webserver.cbl: メインサーバープログラム
対応MIMEタイプ
- HTML: text/html
- CSS: text/css
- JavaScript: application/javascript
- JSON、XML、Plain text、PNG、JPEG、GIF、SVG、ICO、PDF など
- 追加のMIMEタイプ登録は mime-types.cbl ファイルで可能
セキュリティ機能
- パス移動の防止:
.. シーケンスを含むリクエストを遮断
- ディレクトリアクセス制限: 現在のディレクトリおよびその配下のディレクトリ内のファイルのみを配信
- 安全なファイルハンドリング: ファイルシステムにアクセスする前にパスを検証し妥当性を確認
制限事項
- シングルスレッドベース: 一度に1件のリクエストしか処理できない
- SSL/TLS（HTTPS）非対応
- 最大ファイルサイズ: 64KB
- 行順次ファイル構成（テキストファイル）のみ対応
- キャッシュ、圧縮、範囲リクエストなどは未対応
2件のコメント
コメントの書き方もかなり不思議ですね、、
Hacker Newsのコメント
COBOLの固定形式モードが実際に使われているのを見られてうれしい
COBOLには自由形式（free mode）と固定形式（fixed format mode）の2つのモードがある
固定形式はパンチカード時代の名残で、特定の桁位置によって区切られる
1〜6桁目: 行番号
7桁目: インジケータ文字（例:
*はコメント。サンプルコードで確認可能）8〜11桁目: 特別な division マーカー。場合によってはそれ以上を占めることもある（サンプルファイル）
12〜72桁目: 実際の COBOL 文
73〜80桁目: プログラマ向けメモなど、自由に使える領域
この構造は現代の開発者やツールには負担になるため、自由形式モードが推奨されている
とはいえ固定形式モード特有の魅力もあるので、2025年に COBOL を使うなら本気でレトロな雰囲気を楽しんでみるのもおすすめ
73〜80桁目は、カードがばらばらになったときにソーターで再整列できるよう、通し番号を書いておく用途でも使われていた
COBOL カードの実感を味わいたければ、このリンクで COBOL カードを選べる
さらに昔っぽくしたければ、まずコーディングシートにプログラムを書いて、それをアシスタントがキーパンチする形も試せる（サンプル）
昔の Fortran も固定桁構造だったが、桁の割り当てが違うだけだった
共通しているのは 73〜80桁目をカード整列用の通し番号などのために空けていたこと
実際のカードを使ったことはないが、落としたり順番を間違えたりしやすかったはずなので、通し番号やソーターは非常に有用だっただろうと思う
この点は自分も印象に残った
ただ、Makefile では cobc の
-freeオプションを使っていたのが面白かったみんな「仕事に最適な道具を使え」と言うのに、こと COmmon Business Oriented probLems となると COBOL は選ばない
それは MUMPS にもまったく同じことが言える
人は自分が素晴らしい選択をできることを見落としがちだ
COBOL を選ばないというより、最初から検討対象にすらしていないことのほうが大きい
そもそも、いつどんな理由で「仕事に最適な道具」という言い方をするのか気になる
うちの会社は創業から 40〜50 年以上経っている
今でも業務の 90% は COBOL ベースだ
現場の社員は RM/COBOL と RM/PANELS で作られたブルースクリーン上で作業している
2010年代までは COBOL で HTML を生成していたが、HTTP リクエストを直接受けていたわけではない
その代わり Apache の背後に RPC レイヤーを置き、HTTP リクエストを CGI に変換して COBOL に渡していた
COBOL プログラムが HTML 文字列を CGIRPC インターフェースに送り、その結果が Web ページとしてブラウザに表示される
今でも XML サービスなどを通じてこれを使い続け、既存の Web アプリを補完している
正直、このプロジェクトはそれよりずっとクールな体験だ
コードのほぼすべての行にコメントが付いているのは興味深い
「コードはそれ自体がドキュメントであるべきだ」という言葉の前提を考え直させられる
それはコードを読む人がその言語を知っていること、そして場合によっては「自己文書化」が可能であることを前提にしている
COBOL に慣れた人なら COBOL も十分に自己文書化できると言うかもしれないが、自分にはよく分からない
git のコミット d9a5e3e に「興味を持った人が各行の役割を理解できるようコメントを追加した」とあるのを確認できる
「コードはその言語を知っている人が読むものだ」という話は文脈次第だと思う
一人で、あるいは誰かのために学びながら書くコードなら、各行が何をしているかコメントするのは自然だ
一方で専門的な環境では、チームが言語に精通している前提で、たいていはコメントなしで構造的に保つほうが良い選択かもしれない
銀行では COBOL コードはもともと自然言語のようだから自己文書化されている、と主張する人もいて、その話を聞いたときは笑いそうになった
冗談っぽく見えるけれど本当に気になったので質問してみる
COBOL のセキュリティ関連の保証について詳しい人はいないだろうか
たとえば、COBOL ではメモリ範囲外アクセスが可能なのか、C や Rust のように「うっかり」で脆弱性が生まれる危険がどの程度あるのか知りたい
COBOL でメモリ範囲外アクセスをすると、現代のコンパイラならエラーを出すし、仮にコンパイルまたは実行できてもランタイムエラーや即時クラッシュになる
ただし、COBOL の reference modification 機能によって、意図的にデータ境界の外のメモリを参照できる点はある
完全に安全というわけではないが、コンパイル段階で多くのミスや誤用が検出されるため、事故の発生率はかなり低くなる
http handler を見て自分も同じことが気になった
メソッドとパスの間の空白が欠けていた場合、バッファオーバーランの可能性があるように思えた
実際に動かしてはいないが、そういう懸念を抱いた
CALL "socket"が何をしているのかもっと知りたいCALL はサブプログラム呼び出しだが、
"socket"がどこで定義されているのか分からない以前、自分でも COBOL の Web サーバーを作ってみようかと思ったことがあるが、GnuCOBOL FAQ で CGI なら可能と読んだだけで、それ以上は進めなかった（FAQ 参照）
このプロジェクトをもっと深く見てみたい
本当に興味深い
"socket"はシステムコール呼び出しかもしれないCOBOL が一部の政府機関や企業サイトのバックエンドとして使われていた時代があった
当時のサイトは HTML が 100 桁固定幅フォーマットで出力される独特の見た目をしていて、すぐにそれと分かった
どんな言語でもプログラミングできると思っていたが、この COBOL プロジェクトを見ると、Assembly のほうがむしろすっきりしていてエレガントに感じられるほどだ
Jms Dnns! このプロジェクトは本当に発想を広げてくれる素晴らしい仕事だ
両方の言語で高さ数十 cm はあるソースコードの束を扱った立場からすると、COBOL のほうが頭の中で整理しやすかった
もちろん人それぞれだとは思う
本当に素晴らしいプロジェクトだ
COBOL 入門のコツがあればぜひ聞きたい
これで COBOL on Cogs のビジョンにまた一歩近づいたことになる
coboloncogs.org でさらに確認できる