A note from the urllib3 fixes to this:  They chose to go the route of auto-%-encoding the offending characters in URLs instead.  I do not think the stdlib should do this.

One thing to note though is that they claim URLs with spaces embedded in them are apparently somewhat common in the world, we might want to relax our check to not include space (\x20) in the rejected characters for that reason.

A space alone cannot be used for injection.  Someone could append an incorrect HTTP protocol version to a request using it " HTTP/1.0" but that would be followed by the actual " HTTP/x.y" generated by our library which at that point is up to the server to parse and or reject as odd.  Without the ability to inject \r\n the headers to go with the protocol cannot be modified; so a change in protocol version could at most alter how some headers may be treated.  Worst case: they upgrade/downgrade the http version in a non-pedantic server - i believe this to be low impact (feel free to prove me wrong with a working example against a common server).  Best case: The server rejects the unparseable request or considers their " HTTP/1.0" to be part of their URL path.

In a world where unescaped spaces in URLs are common, some servers _might_ already take the strategy of splitting only on the first and last spaces in the request line anyways, considering everything in the middle to be the url with embedded spaces.