fix(state): omit Content-Type when response has no body

[soyuka]

Fixes #2929.

Summary

Per RFC 7230 §3.3.2: "A sender MUST NOT generate a Content-Type header field in a message that does not contain a payload body."

Per RFC 7230 §3.3.3: responses with status 204 No Content, 205 Reset Content, and 304 Not Modified MUST NOT include a payload body.

HttpResponseHeadersTrait::getHeaders() was unconditionally setting Content-Type even when the operation produced no body (e.g. output: false) or when the status code mandates an empty body (DELETE → 204).

Change

Gate the Content-Type header behind:

$hasBody = $hasOutput && !\in_array($status, [
    Response::HTTP_NO_CONTENT,
    Response::HTTP_RESET_CONTENT,
    Response::HTTP_NOT_MODIFIED,
], true);

Where $hasOutput is false when output['class'] === null (i.e. output: false was passed to the operation).

Tests

Three new unit tests in RespondProcessorTest:

• testDoesNotSetContentTypeWhenOutputIsFalse — POST with output: false + 204
• testDoesNotSetContentTypeWhenOutputIsFalseWithCreatedStatus — POST with output: false + 201
• testDoesNotSetContentTypeOnBodylessStatusCodes — DELETE (default 204)

Note on Symfony Response::prepare()

Symfony's Response::prepare() automatically re-adds a Content-Type header derived from the request format for all responses whose status is not 204 or 304 (see Response::isEmpty()). For the typical output: false flow (status defaults to 204 via InputOutputResourceMetadataCollectionFactory), Symfony's strip aligns with this fix and the header is fully omitted on the wire.

For the edge case where a user sets output: false together with a status that Symfony does not treat as empty (e.g. 201, 202), Symfony will re-add Content-Type. A follow-up tied to #7875 (which introduces ResponseHeaderParameter for declarative header customization) can add a kernel.response listener that honours the no-body intent regardless of status.

[dunglas]

Unrelated, but the charset attribute unconditionally may not be a good idea. For instance JSON, doesn't have a charset attribute and including it is not valid, and can break some strict clients.

[soyuka]

Indeed this is to avoid breaking tests we had that before. Lets investigate this in another issue.