Ollama Community Proposes Request-Parsing Fix After Trailing JSON Noise Is Ignored and Inference Starts

On October 3, the Ollama community reported that version 0.35.1 may accept a malformed POST /api/generate request: a valid JSON object is followed by non-JSON text, yet the server still returns HTTP 200 and begins generation. This can hide serialization errors in an apparently successful response, making local inference services and proxy workflows harder to debug. Issue report

The reporter used gemma4:e4b on Apple hardware running macOS. They appended NOT JSON HERE to an object containing the model, prompt, and generation options, and configured a non-streaming response. All three tests returned generated text. In comparison, valid JSON succeeded in every test, while truncated JSON consistently returned HTTP 400. These results point to trailing data going unchecked, but this is a community reproduction in a single environment and does not establish that all versions and endpoints behave the same way. Reproduction details

A fix PR proposed the same day points to the existing ShouldBindJSON path as the cause: parsing stops after the first value, so remaining bytes are ignored. The proposal calls for decoding a single JSON value and then checking the rest of the request body, returning 400 if it contains non-whitespace data. It also adds handler tests that reject trailing noise and accept trailing whitespace. As of this check, the PR remains open, and its listed test plan should not be treated as verified or officially released. Proposed fix

The official documentation specifies application/json as the request body format for this endpoint, while the format field controls structured output generated by the model. Requiring an answer to conform to a JSON Schema therefore does not verify that the complete request sent to the server is valid JSON; engineering teams need to check these two boundaries separately. API documentation

Integration teams can add valid, truncated, and trailing-data cases to deployment acceptance checks, rather than relying on HTTP 200 alone to determine whether a request is correct. They should track whether the fix is merged, which version includes it, and whether other endpoints use the same parsing approach. Current public evidence supports an input-validation defect; it has not established an authorization bypass, data exposure, or an exploitable security attack.