Flask/Werkzeug: Don't send content-type header with 204 response?

[rsyring]

I received a warning form the Python webtest library when responding with a 204 HTTP status code b/c Flask (or Werkzeug, I didn't dig to find where it happens) adds a Content-Type header by default: ('Content-Type', 'text/html; charset=utf-8').

Led me to a discussion with Claude about what the spec says regarding. It sounds like it's not prohibited but would make sense to not add the header if the status code is 204.

It's a small thing, but should Flask/Werkzeug take the status code into account before adding a content type header?

[davidism]

Werkzeug Response.default_mimetype sets the Content-Type header when creating a response if it's not given. Response.get_wsgi_headers removes the Content-Length header when sending a 204 response.

Content-Length spec directly says that a 204 response must not contain this header, and Werkzeug therefore removes it. Content-Type spec doesn't make any statement about not sending the header. While we do have the logic in place already to do something on certain status codes, I'm wary of adding this. It's not required according to spec, and might result in more requests to remove other headers despite the spec not requiring it.

If you're commonly sending 204 responses, you can write a helper to produce a response in the exact form you need:

def make_204(...):
    response = Response(status=204)
    del response.headers["content-type"]
    ...
    return response

You can also override Flask.response_class, or Flask.make_response, to add extra behaviors you need.

[rsyring]

It's not required according to spec, and might result in more requests to remove other headers despite the spec not requiring it.

Fair enough. :)

Thanks for the discussion and suggestions you provided.

[davidism]

I meant to look at the conversation you linked as well, to see what Claude was outputting, but got a "temporarily unavailable" error page. Tried again today and got the same thing, even though Claude seems to be up. So I think that link may be bad.

[rsyring]

Huh...the share link only works for me when I login. A private window shows what you saw. They should get AI to fix that. ;o)

Here is the pertinent bit, which is basically what you were saying above:

Based on the HTTP specifications and my search results, here's what the specs say about Content-Type headers for 204 responses:

The HTTP specification does NOT explicitly prohibit Content-Type headers for 204 responses, but there are strong practical and logical reasons to omit them:

What the specs say:

1. RFC 2616 (HTTP/1.1): Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. Since there is no content, then there is no reason to specify a Content-Type header. http - What Content-Type should a 204 No Response use? - Stack Overflow
2. RFC 7231: The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. RFC 7231 (Obsoleted): 3 of 5
3. RFC 7230: The spec explicitly prohibits certain headers for 204 responses - A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content)... A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). HTTP 204 No Content with Transfer-Encoding header violates

Key Points

• No explicit prohibition: The specs don't explicitly forbid Content-Type headers for 204 responses
• Logical reasoning: Since there's no content, there's no need to specify what type that non-existent content is
• Practical issues: Superagent (and possibly other clients) will try to parse the body if content-type has been set. HTTP 204 (no content) should not return "Content-Type": "application/json" · Issue #621 · strongloop/loopback
• Other headers ARE prohibited: Transfer-Encoding and Content-Length headers are explicitly forbidden

So while not strictly required by the specification, omitting the Content-Type header for 204 responses is considered best practice and avoids potential client-side parsing issues

Could be some copy/paste issues above. It doesn't copy or past cleanly from their UI.