We're using email.parser.HeaderParser to parse our headers, which uses some behaviour defined in email-specific draft RFCs.
As a result, the behaviour when the Content-Type is malformed is to set it to text/plain, which doesn't really make sense (and may break things) in a general HTTP application.

Ideally, we should consider replacing this so that it defaults to application/octet-stream (or maybe None?):
https://www.rfc-editor.org/rfc/rfc9110#section-8.3-5