Starlette allows NaN as input JSON, but not as return JSON

[akalipetis]

Although Starlette (correctly) does not allow NaN to be returned as part of a JSON response, it does allow NaN fields when receiving input data.

For example, the following would fail:

# server.py
import uvicorn
from starlette.applications import Starlette
from starlette.responses import JSONResponse

app = Starlette()


@app.route("/", methods=["POST"])
async def log(request):
    return JSONResponse(await request.json(), 200)


if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8000)

# crash.py
import requests

requests.post('http://localhost:8000', json={'oops': float('nan')})

If that's something that we'd like to address, I'm happy to open a PR, which can do either of these things:

1. Raise an HTTPException(400, "NaN, +Inf, -Inf are not allowed")
2. Allow adding extra **kwargs to request.json() which would then be passed to json.loads() under the hood

[tomchristie]

Okay - we're not actually catching and handling malformed JSON automatically in any case, so that's probably a more pressing issue prior to this. But yes, I'd be happy to have nan on input end up with exactly the same behavior as any other malformed JSON.

[akalipetis]

Thanks for the reply Tom, I'll read the internals a bit more and try to draft something to hear your thoughts 😀

[tomchristie]

I'm going to convert this to a discussion, since it's marginal.

I think we'd consider pull requests here that switched the JSON parsing to be actually JSON compliant, rather than "okay sure but also here's a coupla constants that we also think are okay. lol".

Here's the kinda thing you'd need...

>>> def invalid_constant(value):
...     raise ValueError("Invalid JSON {value!r}")
... 
>>> json.loads("NaN", parse_constant=invalid_constant)

Although really we'd want any change in behaviour there to raise json.decoder.JSONDecodeError, same as for any other invalid JSON, which might be more complex than we'd first expect.