The bug: Our http client can get stuck infinitely reading len(line) < 64k lines after receiving a '100 Continue' http response.  So yes, this could lead to our client being a bandwidth sink for anyone in control of a server.

Clear issue: That's a denial of network bandwidth and the denial of service in terms of CPU needed to process read and skip such lines.  The infinite lines are size bounded and are not buffered so there is no memory based DoS.

Maybe issue: If a the underlying socket has a timeout set on it, it can be used to prevent the timeout from triggering by sending a line more often than the timeout.  this is a denial of service by making a http client connection that an author may have assumed would timeout based on their socket.setdefaulttimeout() settings hang forever.

I expect there are plenty of other ways to accomplish the latter in our http client code though.  Ex: A regular response with a huge content length where one byte is transmitted occasionally could also effectively accomplish that.  The stdlib http stack doesn't have its own overall http transaction timeout as a feature.