Python HTTP Proxy POST Bodies Can Be Buffered in rfile
Read a Python HTTP proxy request through the handler's buffered input instead of waiting for bytes that have already left the socket buffer.
The forward proxy reads the request line and headers, forwards them, then waits in select for a POST body. The client has already sent it. Both sides appear to be waiting for the other.
With Python's BaseHTTPRequestHandler, reading the headers goes through rfile, a buffered input stream. That stream can read ahead and hold bytes belonging to the body. Waiting on the underlying socket only asks whether its file descriptor is ready; it does not ask whether the Python stream already contains usable data.
Follow the buffer that read the headers
Read the body through self.rfile too. Do not switch to self.connection.recv after parsing the headers with the buffered stream. Otherwise the code can bypass bytes already retained by that stream and wait for data that will never be sent again.
Passing rfile itself to select does not make select inspect its Python buffer. The readiness API works through the object's file descriptor.
For a request with one valid Content-Length and no Transfer-Encoding, consume exactly the declared number of bytes, handling premature end of input and your size and time limits. Do not read until EOF: a client using a persistent connection may keep the connection open after finishing the request.
Make framing an explicit part of the proxy
Chunked request bodies need chunked framing support. They cannot be read by looking for a Content-Length that is absent. Ambiguous length metadata needs a defined rejection path, rather than selecting whichever header seems convenient.
A blocking handler can keep using its stream interface with bounded reads. An event-driven proxy needs a buffer model that integrates parser read-ahead with readiness handling. Changing a timeout will not reconcile two independent consumers of the same socket.
This diagnosis is specific to where the incoming bytes are held. Once the proxy has consumed the right body, it still needs to forward that body with consistent HTTP framing. The standard http.server handler is a useful place to understand the mechanism, but it is not a production forward-proxy implementation.