fastapi: FastAPI always returns content, even if 204 no content status code is set.

You could instead set the response class for that path operator to be Response instead of the default JSONResponse. Then it won’t convert None into JSON. So w/ your example above it would be:

@app.get("/", status_code=HTTP_204_NO_CONTENT, response_class=Response)
def read_root():
    print("d")

which correctly returns b"".

note, if you are doing this on multiple endpoints, you can set the default response class on your router, or even your entire app. https://fastapi.tiangolo.com/advanced/custom-response/#default-response-class

httptools will return null and h11 will return empty but raises an exception if you don’t explicitly return a Response but declare the status code to be 204.

you have to explicitly return an empty Response instead of implicitly returning None, which is what happens when you don’t return anything.

return Response(status_code=HTTP_204_NO_CONTENT)

also, see: https://github.com/tiangolo/fastapi/issues/2253

Thanks @falkben. I found this solution also but I believe it should be handled by the framework. It’s fairly simple to implement hence the PR I submitted. Returning 204 with data is invalid according to the standards so FastAPI should detect such scenario and handle it accordingly IMO

Is this fixed by https://github.com/tiangolo/fastapi/releases/tag/0.79.0 ?

I don’t think we need to handle all possible use-cases.

This bug is about the specific case where the route is defined with (default) status_code=HTTP_204_NO_CONTENT, because if you do not also override other defaults (i.e. the extra setting @falkben describes, or expressly returning a Reponse in your handler), FastAPI generates an invalid HTTP responses.

Documenting

If you set status_code=HTTP_204_NO_CONTENT, you must also set response_class=Response or some other response_class that does the right thing

is less-kind to the library user than

If you set status_code=HTTP_204_NO_CONTENT, the default response_class will be Response, rather than JSONResponse

as in the latter case, the user specifying their status code gets valid behaviour for that status code out-of-the-box, and retains exactly the same amount of control for the user to override the defaults that exists now. Overriding that response_class default stops being mandatory, and natural things like not returning a value from a 204-typed API remain explicitly natural. And if the user decides that returning a body in their 204 response is actually desired, then that’s still possible explicitly.

This also means the list of the HTTP status codes for which no response body is allowed by the standard is kept in the library code, rather than in the documentation and the user’s code-base.

I liked the idea of EmptyResponse to be the default response_class when a status_code which disallows response bodies is specified, but it seems Starlette upstream is going in a different direction there, simply explicitly excluding the Content-Length header in 204 (and similar) responses, which has the effect that you cannot provide a message body in a 204 response. What you get if you try (i.e the example in this issue) is a 204 response with no body, plus a bunch of garbage data on the wire for which interpretations and handling varies. I’ve no idea what the various Python http libraries will make of this, but I suspect it won’t magically fix this problem by discarding any unintentionally-produced body data.

unicorn --http httptools

Can you try to run with httptools instead of h11?