Thanks for working with me to reproduce and understand the issue. I'm a little surprised that with the sample which sets the protocol version you're still not seeing the issue.

If I create a directory tree, e.g.

repro
├── foo/
└── server.py

where `server.py` is the sample I gave, and run `server.py`, I find that `curl localhost:8000/foo` hangs. `curl -v` includes a message as part of its output which states that it's waiting for the connection to close.

Full verbose output:
```
$ curl localhost:8000/foo -v
*   Trying 127.0.0.1:8000...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET /foo HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: SimpleHTTP/0.6 Python/3.8.5
< Date: Thu, 06 May 2021 15:53:13 GMT
< Location: /foo/
* no chunk, no close, no size. Assume close to signal end
<
^C
```


This holds over a few python versions: 3.6.12, 3.8.5, and 3.9.1 . That's probably a good enough sample since the relevant code hasn't changed in the stdlib.

It's doubtful that the exact version of curl matters for this. I can also see the issue with Firefox opening `localhost:8000/foo`. It hangs without processing the redirect.


Running the sample I gave, you're seeing curl exit cleanly? I wonder, with verbose output, maybe there's some useful message that will tell us why it's exiting. Does it not print the message, "no chunk, no close, no size. Assume close to signal end" ?


> Note: the existing behavior is 10+ year old and don't want to introduce changes if it is not a bug.

I completely understand this stance. I believe it is a bug, but that it's rare enough that hasn't been filed or resolved, in spite of its age.

Some browsers (e.g. Chrome) process redirects without waiting for a payload, so they would mask the issue. Plus, it only shows up when the protocol_version is set.

I had a script at work with this issue for over a year without anyone running into the hangs. A coworker who prefers Firefox noticed the issue only recently, and I traced that back to this behavior.
So even in my case, I didn't stumble across this issue until we'd been using the same test script with the bug in it for a long time.