This is related to #46331 but not directly dependent - it's a separate issue I've just noticed en route.

Previously, if you removed both the content-length and transfer-encoding headers, everything was sent as normal, and the connection would still be kept alive by default. This is problematic, because without those headers to declare the size of the message body, the only way the client knows when the body is completed is when the connection closes. With KA, the connection doesn't close for ages.

See https://www.rfc-editor.org/rfc/rfc7230#section-3.3.3 for more details on this message body handling logic. This is the final case (7):

Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.

This meant that in effect, if you removed both headers then every response came with a 5 second delay at the end (the default KA timeout) before the client could process it.

With this PR, if you remove both headers then the connection closes automatically immediately, so the client knows straight away that it has received the whole message body and everything works correctly.

This does behave slightly differently with & without #46331:

• Currently, without that PR, this only affects code that removes the content-length & transfer-encoding headers, but does not remove the connection header (because doing so disables KA, which solves the issue).
  Note that the only test covering this does exactly that, so the modified test here actually still passes on main even without this change.
• Once that other PR is merged, this issue would affect any code that removes both headers, regardless of whether they remove the Connection header, because doing so no longer disables KA. The modified test here does fail if run against that PR branch (and does pass when run with this test + fix on top of that branch).