POST-kroppar i en Python HTTP-proxy kan buffras i rfile
Läs en Python HTTP-proxyförfrågan genom handläggarens buffrade indata i stället för att vänta på byte som redan lämnat socketbufferten.
Vidarebefordringsproxyn läser förfrågningsraden och rubrikerna, vidarebefordrar dem och väntar sedan i select på en POST-kropp. Klienten har redan skickat den. Båda sidor verkar vänta på varandra.
Med Pythons BaseHTTPRequestHandler går läsningen av rubrikerna genom rfile, en buffrad indataström. Den strömmen kan läsa i förväg och hålla byte som hör till kroppen. Att vänta på den underliggande socketen frågar bara om dess fildeskriptor är redo; det frågar inte om Python-strömmen redan innehåller användbara data.
Följ bufferten som läste rubrikerna
Läs kroppen också genom self.rfile. Byt inte till self.connection.recv efter att du tolkat rubrikerna med den buffrade strömmen. Annars kan koden hoppa över byte som strömmen redan håller och vänta på data som aldrig skickas igen.
Att ge rfile självt till select får inte select att granska dess Python-buffert. Beredskaps-API:t arbetar genom objektets fildeskriptor.
För en förfrågan med en giltig Content-Length och ingen Transfer-Encoding, förbruka exakt det deklarerade antalet byte, och hantera tidigt slut på indata samt dina storleks- och tidsgränser. Läs inte till EOF: en klient med beständig anslutning kan hålla anslutningen öppen efter att förfrågan är klar.
Gör inramning till en explicit del av proxyn
Chunkade förfrågningskroppar behöver stöd för chunkad inramning. De kan inte läsas genom att leta efter en Content-Length som saknas. Tvetydig längdmetadata behöver en definierad avvisningsväg, i stället för att välja den rubrik som verkar bekväm.
En blockerande handläggare kan fortsätta använda sitt strömgänssnitt med begränsade läsningar. En händelsestyrd proxy behöver en buffertmodell som integrerar parserns förhandsläsning med beredskapshanteringen. Att ändra en timeout försonar inte två oberoende konsumenter av samma socket.
Den här diagnosen gäller specifikt var de inkommande byten hålls. När proxyn har förbrukat rätt kropp måste den fortfarande vidarebefordra den kroppen med konsekvent HTTP-inramning. Standardhandläggaren http.server är en användbar plats för att förstå mekanismen, men den är inte en produktionsimplementation av en vidarebefordringsproxy.