POST-bodies van een Python HTTP-proxy kunnen in rfile gebufferd worden
Lees een Python HTTP-proxyverzoek via de gebufferde invoer van de handler in plaats van te wachten op bytes die de socketbuffer al hebben verlaten.
De forward-proxy leest de verzoekregel en de headers, stuurt ze door en wacht dan in select op een POST-body. De client heeft die al verzonden. Beide kanten lijken op elkaar te wachten.
Met Python's BaseHTTPRequestHandler loopt het lezen van de headers via rfile, een gebufferde invoerstroom. Die stroom kan vooruit lezen en bytes vasthouden die bij de body horen. Wachten op de onderliggende socket vraagt alleen of de file descriptor klaar is; het vraagt niet of de Python-stroom al bruikbare data bevat.
Volg de buffer die de headers las
Lees de body ook via self.rfile. Schakel niet over naar self.connection.recv nadat je de headers met de gebufferde stroom hebt geparseerd. Anders kan de code bytes overslaan die die stroom al vasthoudt en wachten op data die nooit meer wordt verzonden.
rfile zelf aan select geven zorgt er niet voor dat select de Python-buffer inspecteert. De gereedheids-API werkt via de file descriptor van het object.
Voor een verzoek met één geldige Content-Length en zonder Transfer-Encoding verbruikt u precies het opgegeven aantal bytes, en behandelt u vroegtijdig einde van de invoer plus uw grootte- en tijdslimieten. Lees niet tot EOF: een client met een persistente verbinding kan de verbinding open houden nadat het verzoek klaar is.
Maak framing een expliciet onderdeel van de proxy
Chunked verzoekbodies vereisen ondersteuning voor chunked framing. Ze kunnen niet worden gelezen door te zoeken naar een ontbrekende Content-Length. Onduidelijke lengtemetadata vereist een gedefinieerd afwijzingspad, in plaats van de header te kiezen die handig lijkt.
Een blokkerende handler kan zijn stroominterface blijven gebruiken met begrensde leesacties. Een gebeurtenisgestuurde proxy heeft een buffermodel nodig dat vooruit lezen van de parser integreert met gereedheidsafhandeling. Een timeout wijzigen verzoent twee onafhankelijke verbruikers van dezelfde socket niet.
Deze diagnose gaat specifiek over waar de inkomende bytes worden vastgehouden. Zodra de proxy de juiste body heeft verbruikt, moet hij die body nog doorsturen met consistente HTTP-framing. De standaard http.server-handler is een nuttige plek om het mechanisme te begrijpen, maar het is geen productie-implementatie van een forward-proxy.