This could potentially be seen as a couple of different issues, but they're all tightly overlapping, and can probably all be solved with a common fix. This also overlaps with #2215.

Currently, Content-Length: 0 may be automatically applied to any 204 response (just like 101 responses in #2215). Also, other Content-Length headers can be set explicitly within a service, or be implied by a body with a KnownLength. A 204 response MUST NOT contain either Content-Length or Transfer-Encoding.

On the other hand, a 304 response will never have a body, but MAY contain either Content-Length or Transfer-Encoding. Currently, the only way to get a Content-Length header attached to a 304 response is to try to actually send a Body of that length.

The headers made in response to a HEAD request should match those which would have been made for a GET request. Currently, if a service attempts to force chunked encoding on what might otherwise imply a Content-Length header be added, GET requests will see Transfer-Encoding: chunked while a HEAD request receives Content-Length: .... It is not currently possible to set Transfer-Encoding on a response to a HEAD request.

It seems the things which need to be fixed are:

• For 204s, 100..199s, and any 2xx response made to a CONNECT request, any Content-Length or Transfer-Encoding header set by a service must be dropped. Further, neither header should be automatically added.
• Any Content-Length or Transfer-Encoding header set by a service for any kind of response should be handled the same for GET and HEAD requests.
• Any Content-Length or Transfer-Encoding header set by a service for a 304 response should be left alone. (perhaps unless a BodySize::Known greater than 0 conflicts with a Content-Length header, which could be an error?)

For reference, https://httpwg.org/specs/rfc7230.html#rfc.section.3.3