POST телата на Python HTTP прокси можат да се баферираат во rfile
Читајте го барањето на Python HTTP прокси преку баферираниот влез на ракувачот наместо да чекате бајти што веќе го напуштиле баферот на сокетот.
Пропусниот прокси ја чита линијата на барањето и заглавијата, ги препраќа, потоа во select чека POST тело. Клиентот веќе го испратил. Двете страни изгледаат како да чекаат една со друга.
Со BaseHTTPRequestHandler на Python, читањето на заглавијата поминува низ rfile, бафериран влезен тек. Тој тек може да чита однапред и да држи бајти што му припаѓаат на телото. Чекањето на основниот сокет само прашува дали неговиот датотечен дескриптор е подготвен; не прашува дали Python текот веќе содржи употребливи податоци.
Следете го баферот што ги прочита заглавијата
Читајте го телото и преку self.rfile. Не преминувајте на self.connection.recv откако заглавијата ќе ги обработите со баферираниот тек. Инаку кодот може да ги заобиколи бајтите што тој тек веќе ги држи и да чека податоци што никогаш повеќе нема да бидат испратени.
Предавањето на самиот rfile на select не прави select да го прегледа неговиот Python бафер. API-то за подготвеност работи преку датотечниот дескриптор на објектот.
За барање со едно валидно Content-Length и без Transfer-Encoding, потрошете точно објавениот број бајти, справувајќи се со предвремен крај на влезот и со вашите ограничувања за големина и време. Не читајте до EOF: клиент со постојана врска може да ја остави врската отворена откако ќе го заврши барањето.
Направете рамкирањето експлицитен дел од проксито
Поделените тела на барања бараат поддршка за поделено рамкирање. Не можат да се читаат со барање на отсутен Content-Length. Двосмислените метаподатоци за должина бараат дефинирана патека за одбивање, наместо избор на заглавието што изгледа погодно.
Блокирачкиот ракувач може да го продолжи користењето на својот тек-интерфејс со ограничени читања. Прокси управувано од настани бара модел на бафер што го интегрира читањето однапред на парсерот со справувањето со подготвеност. Менувањето на таймаут нема да помири два независни потрошувачи на истиот сокет.
Оваа дијагноза е специфична за тоа каде се држат дојдовните бајти. Откако проксито ќе го потроши точното тело, сепак треба да го препрати тоа тело со конзистентно HTTP рамкирање. Стандардниот http.server ракувач е корисно место за разбирање на механизмот, но не е продукциска имплементација на пропусно прокси.