Ollamaコミュニティがリクエスト解析の修正を提案、JSON末尾の余分なデータが無視され推論が実行される可能性

Ollamaコミュニティは10月3日、0.35.1のPOST /api/generateが、形式上完全に適合していないリクエストを受け付ける可能性を報告した。先頭部分が有効なJSONオブジェクトで、その後に非JSONテキストが付いていても、サーバーはHTTP 200を返し、生成を開始するという。これにより、呼び出し側のシリアライズエラーが成功レスポンスに隠れ、ローカル推論サービスやプロキシ処理のデバッグが難しくなる可能性がある。問題報告

報告者はmacOS搭載のApple製ハードウェアでgemma4:e4bを使い、モデル、プロンプト、生成オプションを含むオブジェクトの後ろにNOT JSON HEREを追加し、非ストリーミングレスポンスを設定した。3回のテストすべてで生成テキストが返された。比較対象では、有効なJSONはすべて成功し、途中で切れたJSONはすべてHTTP 400を受け取った。この結果は末尾のデータが検査されていない可能性を示すが、単一環境でのコミュニティによる再現であり、すべてのバージョンやエンドポイントで同じ挙動が起きるとは限らない。再現記録

同日に提案された修正PRは、原因を従来のShouldBindJSON経路にあると指摘している。最初の値を解析した時点で処理が止まり、残りのバイト列が無視されるという。提案では、単一のJSON値をデコードした後もリクエスト内容の確認を続け、空白以外のデータが残っていれば400を返すよう求めている。また、末尾の余分なデータを拒否し、末尾の空白は許容するハンドラーのテストも追加している。確認時点でPRはまだオープンであり、記載されたテスト計画を検証済み、または正式リリース済みとみなすことはできない。修正提案

公式ドキュメントでは、このエンドポイントのリクエストボディはapplication/jsonとされている。一方、formatフィールドが制御するのはモデルが生成する構造化出力だ。そのため、回答をJSON Schemaに準拠させても、サーバーに送るリクエスト全体が有効なJSONかどうかは検証できない。エンジニアリング上、この2つの境界はそれぞれ確認する必要がある。APIドキュメント

統合チームは、デプロイ時の受け入れテストに、有効なJSON、途中で切れたJSON、末尾に余分なデータが付いたJSONの3ケースを加えるとよい。HTTP 200だけを根拠にリクエストが正しいと判断するのを避けられる。今後は修正がマージされるか、どのバージョンに含まれるか、ほかのエンドポイントも同じ解析方式を採用しているかを確認する必要がある。現時点で公開されている証拠が示すのは入力検証の不備であり、権限回避、データ漏えい、悪用可能なセキュリティ攻撃は確認されていない。