Ollama 社群提出請求解析修補，JSON 尾端雜訊可能被忽略並啟動推論

Ollama 社群在 10 月 3 日回報，0.35.1 的 POST /api/generate 可能接受格式不完整合規的請求：前段是合法 JSON 物件，後段附加非 JSON 文字，伺服器仍回傳 HTTP 200 並開始生成。這會讓呼叫端的序列化錯誤藏在成功回應裡，增加本機推論服務與代理流程的除錯難度。問題回報

回報者在 macOS、Apple 硬體上使用 gemma4:e4b，將包含模型、提示與生成選項的物件後接 NOT JSON HERE，並設定非串流回應。三次測試都取得生成文字；對照組的合法 JSON 均成功，截斷 JSON 則均收到 HTTP 400。這組結果指向尾端資料未被檢查，但仍屬單一環境的社群重現，不能據此推定所有版本與端點都有相同行為。重現紀錄

同日提出的修補 PR 將原因指向原有 ShouldBindJSON 路徑：解析第一個值後便停止，剩餘位元組因此遭忽略。提案要求解碼單一 JSON 值後繼續確認請求內容，若存在非空白資料便回傳 400，同時加入拒絕尾端雜訊、接受尾端空白的處理器測試。截至查核時，PR 仍為開啟狀態，列出的測試計畫也不能視為已通過驗證或正式發布。修補提案

官方文件將此端點的請求主體列為 application/json，而 format 欄位控制的是模型生成的結構化輸出。因此，要求答案符合 JSON Schema，並不能驗證送往伺服器的完整請求是否為合法 JSON；工程上需要分別檢查這兩個邊界。API 文件

對整合團隊而言，可先將合法、截斷與附加尾端資料三種案例加入部署驗收，避免只憑 HTTP 200 判定請求正確。後續應追蹤修補是否合併、納入哪個版本，以及其他端點是否採用相同解析方式。目前公開證據支持的是輸入驗證缺陷，尚未證實權限繞過、資料外洩或可利用的安全攻擊。