204/304 responses should not send body or Content-Length (RFC 9112 compliance)

[JaeHyuckSa]

Currently, Gunicorn forwards 204 and 304 responses even when the app includes a non-zero Content-Length or a body.

According to RFC 9112 , these responses must not include a message body, and Content-Length must be absent or zero.

Expected behavior

For 1xx, 204, 304 responses (and HEAD requests):

• Any response body should be ignored or dropped.
• Content-Length should be removed.

Actual behavior

Gunicorn sends the body and headers as provided by the WSGI app, even when they violate the spec.

[blingblin-g]

Thank you for opening the issue @JaeHyuckSa . I discovered this issue when I deployed it on AWS. I deployed an API that included a body along with a 204 response, and it caused a 502 Gateway Error. All other web frameworks handle this correctly by sending 204 responses without a body and no errors, but it seems only Django behaves this way.

In my opinion, this needs to be fixed. If a fix is indeed necessary, I would like to work on it.

Here is a comparison of how different frameworks behave when dealing with 204 responses:

• Spring: Does not accept data at all (no parameter for data)
• Express: Data is removed and Content-Length is not sent
• NestJS: Data is removed and Content-Length is not sent
• Flask: Data is removed and Content-Length is not sent
• FastAPI: Data is removed and Content-Length is not sent
• Django: Data is removed, but Content-Length is sent

[benoitc]

what should return gunicorn if the app insist to send it ?

[blingblin-g]

@benoitc Thanks for the question. According to RFC 9112, for 204 and 304 responses, Gunicorn should enforce the spec by:

• Ignoring/dropping any provided response body entirely.
• Removing the Content-Length header (or setting it to 0 if required, but preferably removing it to avoid confusion).

This ensures compliance even if the WSGI app tries to send invalid content. As seen in other frameworks (e.g., Flask removes the body and omits Content-Length), this prevents issues like 502 errors on AWS.
If we don't enforce this, it could lead to downstream problems, such as corrupted responses or gateway errors. I'd suggest adding logic in the response handler to filter based on status code.
Happy to discuss or contribute a PR for this!

[benoitc]

Apps should fix it not the gateway imo. Otherwise how will it be fixed by the application ? AN alternative may be discading and warning, but I think we would loose quite of time doing it since we still have to read what is sent by the app. What if it's streaming using chunked encoding?

[pajod]

Is there any situation where Gunicorn erroring out is not the most reasonable course of action? (In the case of nonsensical headers, even still permitting the application or framework to follow up with its error handling.)

In every case I can think of, the application is exposing clearly unintended behavior, and it should be fixed. There is no need to silently work around broken application behavior, since there is no (intentional) client/proxy behavior to retain compatibility for.

[benoitc]

I agree we should return an error there instead of silently discarding it or ignoring the error. The framework or the app should take care of it. Can the patch beeing reworinked this way?