Avoid adding Content-Type to non-body responses

[agners]

Proposed change

The current code sets the content-type header for all responses to the result's content_type property if upstream does not set a content_type. The default value for content_type is "application/octet-stream".

For responses that do not have a body (like 204 No Content or 304 Not Modified), setting a content-type header is unnecessary and potentially misleading. Follow HTTP standards by only adding the content-type header to responses that actually contain a body.

This also avoid reading the body for such requests. It seems that reading the body does not cause issues, but the corresponding Core code avoided reading at all (see home-assistant/core#147899).

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:
• Link to cli pull request:
• Link to client library pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io
• CLI updated (if necessary)
• Client library updated (if necessary)

[mdegat01]

Makes sense to me. A test case would be nice if we can add one although ingress is a bit tricky to test.