POST-Bodys in einem Python-HTTP-Proxy können in rfile gepuffert werden
Lies eine Python-HTTP-Proxy-Anfrage über den gepufferten Eingang des Handlers, statt auf Bytes zu warten, die den Socket-Puffer bereits verlassen haben.
Der Forward-Proxy liest die Anfragezeile und die Header, leitet sie weiter und wartet dann in select auf einen POST-Body. Der Client hat ihn bereits gesendet. Beide Seiten scheinen aufeinander zu warten.
Mit Pythons BaseHTTPRequestHandler läuft das Lesen der Header über rfile, einen gepufferten Eingabestrom. Dieser Strom kann vorauslesen und Bytes halten, die zum Body gehören. Auf den zugrunde liegenden Socket zu warten fragt nur, ob sein Dateideskriptor bereit ist; es fragt nicht, ob der Python-Strom bereits nutzbare Daten enthält.
Folge dem Puffer, der die Header gelesen hat
Lies auch den Body über self.rfile. Wechsle nicht zu self.connection.recv, nachdem du die Header mit dem gepufferten Strom geparst hast. Sonst kann der Code Bytes umgehen, die dieser Strom bereits hält, und auf Daten warten, die nie wieder gesendet werden.
rfile selbst an select zu übergeben bringt select nicht dazu, dessen Python-Puffer zu prüfen. Die Bereitschafts-API arbeitet über den Dateideskriptor des Objekts.
Bei einer Anfrage mit genau einem gültigen Content-Length und ohne Transfer-Encoding konsumiere genau die angegebene Bytezahl und behandle vorzeitiges Eingabeende sowie deine Größen- und Zeitlimits. Lies nicht bis EOF: Ein Client mit persistenter Verbindung kann die Verbindung nach Abschluss der Anfrage offen halten.
Mache Framing zu einem expliziten Teil des Proxys
Chunked-Anfragebodys brauchen Unterstützung für chunked Framing. Sie lassen sich nicht lesen, indem man nach einem fehlenden Content-Length sucht. Mehrdeutige Längenmetadaten brauchen einen definierten Ablehnungspfad, statt den Header zu wählen, der bequem erscheint.
Ein blockierender Handler kann seine Stromschnittstelle mit begrenzten Lesevorgängen weiter nutzen. Ein ereignisgesteuerter Proxy braucht ein Puffermodell, das Vorauslesen des Parsers mit Bereitschaftsbehandlung verbindet. Eine Timeout-Änderung bringt zwei unabhängige Konsumenten desselben Sockets nicht in Einklang.
Diese Diagnose bezieht sich darauf, wo die eingehenden Bytes gehalten werden. Hat der Proxy den richtigen Body konsumiert, muss er ihn noch mit konsistentem HTTP-Framing weiterleiten. Der Standard-Handler http.server ist ein nützlicher Ort, um den Mechanismus zu verstehen, aber keine Produktionsimplementierung eines Forward-Proxys.