POST-legemer i en Python HTTP-proxy kan bufires i rfile

Videresendingsproxyen leser forespørselslinjen og hodene, videresender dem og venter deretter i select på et POST-legeme. Klienten har allerede sendt det. Begge sider ser ut til å vente på hverandre.

Med Pythons BaseHTTPRequestHandler går lesing av hodene gjennom rfile, en bufert inndatastrøm. Den strømmen kan lese forover og holde byte som tilhører legemet. Å vente på den underliggende socketen spør bare om filbeskrivelsen er klar; det spør ikke om Python-strømmen allerede inneholder brukbare data.

Følg bufferen som leste hodene

Les legemet også gjennom self.rfile. Ikke bytt til self.connection.recv etter at du har parset hodene med den buferte strømmen. Ellers kan koden hoppe over byte som strømmen allerede holder, og vente på data som aldri sendes igjen.

Å gi rfile selv til select får ikke select til å undersøke Python-bufferen. Klarhets-API-et arbeider gjennom objektets filbeskrivelse.

For en forespørsel med én gyldig Content-Length og ingen Transfer-Encoding, forbruk nøyaktig det oppgitte antallet byte, og håndter tidlig slutt på inndata samt dine størrelses- og tidsgrenser. Ikke les til EOF: en klient med vedvarende tilkobling kan holde tilkoblingen åpen etter at forespørselen er ferdig.

Gjør innramming til en eksplisitt del av proxyen

Chunkede forespørselslegemer trenger støtte for chunket innramming. De kan ikke leses ved å lete etter en Content-Length som mangler. Tvetydig lengdemetadata trenger en definert avvisningsvei, i stedet for å velge det hodet som virker praktisk.

En blokkerende handler kan fortsette å bruke strømgrensesnittet sitt med avgrensede lesinger. En hendelsesstyrt proxy trenger en buffermodell som integrerer parserens forhåndslesing med klarhetshåndtering. Å endre en timeout forliker ikke to uavhengige forbrukere av samme socket.

Denne diagnosen gjelder spesifikt hvor de innkommende bytene holdes. Når proxyen har forbrukt riktig legeme, må den fortsatt videresende det legemet med konsistent HTTP-innramming. Den standard http.server-handleren er et nyttig sted å forstå mekanismen, men den er ikke en produksjonsimplementering av en videresendingsproxy.