What's needed here is a Decision.  (release managers and steering councils make those)

IMNSHO, this regression is intentional and does not feel like a bug.

The Python HTTP APIs were never designed with an explicit intent to allow violations of the protocol.  That it was "allowed" was an accident because the very old original API design didn't go out of its way to check much.  That doesn't mean it was intended.  Hyrum's Law applies as the (lack of) behavior has been around forever.  So of course someone has written code that depended on that.  But it doesn't make said code right.

We either "be strict in what we produce" or we ignore abuse of the APIs and effectively close all CVEs filed against them as "not a bug, this library is intended to allow abuse when given untrusted input."

If we take the latter route and intended to allow such things, we'd need to explicitly document it as such and guarantee their behaviors.  As noted, disallowing it has already shipped in two stable releases.

When writing tests of particular out of spec queries such that servers can implement good "be lenient in what you accept" behavior, it is better not to depend on specific behaviors of a given http client library to allow you to do so for such tests.

If the decision requires code changes, do not expect me to spend time creating them.  Please feel free to loop me in on PR reviews but I'd rather not review anything without release manager approval of the direction they take things in the first place.