Ang mga POST body ng Python HTTP proxy ay maaaring i-buffer sa rfile
Basahin ang isang kahilingan ng Python HTTP proxy sa pamamagitan ng buffered na input ng handler sa halip na maghintay sa mga byte na umalis na sa buffer ng socket.
Binabasa ng forward proxy ang linya ng kahilingan at mga header, ipinapasa ang mga ito, pagkatapos ay naghihintay sa select ng isang POST body. Naipadala na ito ng kliyente. Pareho silang naghihintay sa isa't isa.
Sa BaseHTTPRequestHandler ng Python, ang pagbasa ng mga header ay dumadaan sa rfile, isang buffered na input stream. Maaaring magbasa nang muna ang stream na iyon at humawak ng mga byte na kabilang sa body. Ang paghihintay sa pinagbabatayang socket ay nagtatanong lamang kung handa na ang file descriptor nito; hindi nito tinatanong kung may magagamit na data na ang Python stream.
Sundin ang buffer na nagbasa ng mga header
Basahin din ang body sa pamamagitan ng self.rfile. Huwag lumipat sa self.connection.recv pagkatapos i-parse ang mga header gamit ang buffered na stream. Kung hindi, maaaring laktawan ng code ang mga byte na hawak na ng stream na iyon at maghintay sa data na hindi na muling ipapadala.
Ang pagpasa ng rfile mismo sa select ay hindi nagiging dahilan upang siyasatin ng select ang Python buffer nito. Gumagana ang readiness API sa pamamagitan ng file descriptor ng object.
Para sa isang kahilingan na may isang valid na Content-Length at walang Transfer-Encoding, ubusin ang eksaktong bilang ng byte na inihayag, habang pinangangasiwaan ang maagang pagtatapos ng input at ang iyong mga limitasyon sa laki at oras. Huwag basahin hanggang EOF: ang kliyenteng gumagamit ng persistent connection ay maaaring iwanang bukas ang koneksyon pagkatapos matapos ang kahilingan.
Gawing tahasang bahagi ng proxy ang framing
Ang mga chunked na POST body ay nangangailangan ng suporta sa chunked framing. Hindi sila mababasa sa pamamagitan ng paghahanap ng Content-Length na wala. Ang malabong length metadata ay nangangailangan ng tinukoy na landas ng pagtanggi, sa halip na piliin ang header na mukhang maginhawa.
Ang isang blocking handler ay maaaring patuloy na gumamit ng stream interface nito na may limitadong pagbasa. Ang event-driven na proxy ay nangangailangan ng buffer model na pinagsasama ang read-ahead ng parser sa paghawak ng readiness. Ang pagbabago ng timeout ay hindi magpapagkasundo sa dalawang independiyenteng mamimili ng parehong socket.
Ang diagnosis na ito ay partikular sa kung saan hinahawakan ang mga papasok na byte. Kapag naubos na ng proxy ang tamang body, kailangan pa rin nitong ipasa ang body na iyon na may pare-parehong HTTP framing. Ang standard na http.server handler ay isang kapaki-pakinabang na lugar upang maunawaan ang mekanismo, ngunit hindi ito isang production forward-proxy na implementasyon.