Pythoni HTTP-proxy POST-kehad saab puhverdada rfile'i

Edasisuunav proxy loeb päringurea ja päised, edastab need ning ootab seejärel select-is POST-keha. Klient on selle juba saatnud. Mõlemad pooled näivad ootavat teist.

Pythoni BaseHTTPRequestHandleri puhul käib päiste lugemine läbi rfile, mis on puhverdatud sisendvoog. See voog võib ette lugeda ja hoida kehale kuuluvaid baite. Alumise soketi ootamine küsib ainult, kas selle failideskriptor on valmis; see ei küsi, kas Pythoni voog sisaldab juba kasutatavaid andmeid.

Järgige puhvrit, mis päised luges

Lugege keha ka self.rfile kaudu. Ärge lülituge self.connection.recv-le pärast päiste parsimist puhverdatud vooga. Muidu võib kood mööda minna baitidest, mida see voog juba hoiab, ja oodata andmeid, mida enam kunagi ei saadeta.

rfile'i enda select-ile andmine ei pane select-i selle Pythoni puhvrit uurima. Valmiduse API töötab objekti failideskriptori kaudu.

Päringu puhul, millel on üks kehtiv Content-Length ja millel pole Transfer-Encodingut, tarbige täpselt deklareeritud arv baite, käsitledes enneaegset sisendi lõppu ning oma suuruse- ja ajalimiite. Ärge lugege EOF-ini: püsivat ühendust kasutav klient võib hoida ühendust pärast päringu lõpetamist avatuna.

Tehke raamimine proxy selgesõnaliseks osaks

Tükeldatud päringukehad vajavad tükeldatud raamimise tuge. Neid ei saa lugeda puuduva Content-Lengthi otsimisega. Mitmetähenduslikud pikkuse metaandmed vajavad määratletud tagasilükkamise teed, mitte mugava päise valimist.

Blokeeriv handler saab jätkata oma voogliidese kasutamist piiratud lugemistega. Sündmuspõhine proxy vajab puhvrimudelit, mis ühendab parseri ettelugemise valmiduse käsitlemisega. Taimauti muutmine ei lepita kokku kahte sõltumatut sama soketi tarbijat.

See diagnoos puudutab seda, kus sissetulevaid baite hoitakse. Kui proxy on õige keha tarbinud, peab ta selle keha ikkagi edasi saatma järjepideva HTTP-raamimisega. Standardne http.server-handler on mehhanismi mõistmiseks kasulik koht, kuid see ei ole tootmiskõlblik edasisuunava proxy teostus.