POST-lichems fan in Python HTTP-proxy kinne yn rfile buffere wurde
Lês in Python HTTP-proxyfersyk fia de buffere yngong fan 'e handler ynstee fan te wachtsjen op bytes dy't de socketbuffer al ferlitten hawwe.
De foarút-proxy lêst de fersykline en headers, stjoert se troch en wachtet dan yn select op in POST-lichems. De klant hat it al stjoerd. Beide kanten lykje op inoar te wachtsjen.
Mei Python syn BaseHTTPRequestHandler giet it lêzen fan 'e headers fia rfile, in buffere ynfierstream. Dy stream kin foarút lêze en bytes hâlde dy't by it lichems hearre. Wachtzjen op 'e ûnderlizzende socket freget allinnich oft syn triemdeskriptor klear is; it freget net oft de Python-stream al brûkbere gegevens befettet.
Folgje de buffer dy't de headers lies
Lês it lichems ek fia self.rfile. Skeakelje net oer nei self.connection.recv neidat jo de headers mei de buffere stream parse hawwe. Oars kin de koade bytes oerslaan dy't dy stream al hâldt en wachtsje op gegevens dy't nea wer stjoerd wurde.
rfile sels oan select jaan makket net dat select syn Python-buffer ûndersiket. De klearheid-API wurket fia de triemdeskriptor fan it objekt.
Foar in fersyk mei ien jildich Content-Length en gjin Transfer-Encoding, ferbrûk krekt it oankundige oantal bytes, en behannelje betiid ein fan ynfier en jo grutte- en tiidlimiten. Lês net oant EOF: in klant mei in permaninte ferbining kin de ferbining iepen hâlde neidat it fersyk dien is.
Meitsje framing in eksplisyt part fan 'e proxy
Chunked fersykslichems hawwe stipe foar chunked framing nedich. Se kinne net lêzen wurde troch te sykjen nei in Content-Length dy't ûntbrekt. Dûbelsinnige lingte-metadata hawwe in definiearre ôfwizingspaad nedich, ynstee fan it kiezen fan 'e header dy't handich liket.
In blokkearjende handler kin syn stream-ynterface mei beheinde lêzingen bliuwe brûken. In evenemint-oandreaun proxy hat in buffermodel nedich dat de foarútlêzing fan 'e parser yntegrearret mei klearheidsôfhanneling. In timeout feroarje sil twa ûnôfhinklike konsuminten fan deselde socket net ferienigje.
Dizze diagnoaze is spesifyk foar wêr't de ynkommende bytes hâlden wurde. As de proxy ienris it goede lichems ferbrûkt hat, moat it dat lichems noch trochstjoere mei konsekwint HTTP-framing. De standert http.server-handler is in nuttige plak om it meganisme te begripen, mar it is gjin produksje-foarút-proxy-ymplemintaasje.