Code change:
A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <del> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </del> <ins> Field values containing CR or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.  Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness if they only appear within safe field value contexts (e.g., data not required by HTTP). </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (e.g., field.parsing).  Field definitions where leading

Related discussion:
text: Right, that makes sense, though more strict handling of field values in 7230 was part of the move away from lenient handling for robustness in 2616.
As an HTTP implementer, I'd like to respectfully plead for you to reconsider here, and align the RFC text with the WHAT-WG text for better real-world interoperability. YOLOing together a HTTP/1.1 implementation that's interoperable but insecure is easy. Writing a secure but non-interoperable implementation is pointless, because no-one will use it. Writing a secure AND interoperable implementation is extremely difficult, because it requires that you find the narrowest possible rules that allow only the things that are required to interoperate, and reject everything else, and that's essentially impossible without browser-maker-level visibility into exactly what weird HTTP implementations are out there. The RFCs are an incredible resource for anyone who's trying to build a high-quality implementation, because they contain so much distilled wisdom on where this line is... except for bits like the field-value production, where if you follow the spec you'll get burned and end up having to YOLO something anyway. It's very frustrating to carefully follow the specs, and then be punished for it. And it makes it hard to justify following the spec versus using some YOLO implementation.
We can't align the text. HTTP has always forbidden bare CR as a line break. Almost all deployed implementations rely on that while parsing CR into field values and (CR)LF as line breaks. If we changed that now, all deployed implementations with a cache would have a security hole, instead of just the two evergreen browsers that broke their own parsers and can easily change them back. What servers have been doing (and slowly deploying) is active removal of bare CR in fields when they do character-by-character parsing, just to fix the new browser brokenness. This is a workaround.
With regard to other CTL characters, many are found in the wild, but it would be a stretch to say that they are interoperable when sent in HTTP. Some might be. I don't think we have time to validate such a change.
The WHAT-WG spec text that NAME linked above forbids NUL, CR, and LF inside field values, while allowing everything else. So I'm not suggesting allowing CR.