Предњи прокси чита линију захтева и заглавља, прослеђује их, а затим у select чека POST тело. Клијент га је већ послао. Обе стране изгледају као да чекају једна другу.

Са BaseHTTPRequestHandler у Python-у, читање заглавља иде кроз rfile, баферисани улазни ток. Тај ток може да чита унапред и држи бајтове који припадају телу. Чекање на основни сокет само пита да ли је његов дескриптор датотеке спреман; не пита да ли Python ток већ садржи употребљиве податке.

Пратите бафер који је прочитао заглавља

Читајте тело и кроз self.rfile. Не прелазите на self.connection.recv након што заглавља обрадите баферисаним током. Иначе код може да заобиђе бајтове које тај ток већ држи и да чека податке који никада више неће бити послати.

Прослеђивање самог rfile-а у select не тера select да прегледа његов Python бафер. API спремности ради кроз дескриптор датотеке објекта.

За захтев са једним важећим Content-Length и без Transfer-Encoding, потрошите тачно објављени број бајтова, обрађујући превремени крај улаза и своја ограничења величине и времена. Не читајте до EOF: клијент са трајном везом може оставити везу отвореном након завршетка захтева.

Учините уоквиривање експлицитним делом проксија

Chunked тела захтева захтевају подршку за chunked уоквиривање. Не могу се читати тражењем Content-Length-а који недостаје. Двосмислени метаподаци о дужини захтевају дефинисану путању одбијања, уместо избора заглавља које се чини прикладним.

Блокирајући руковалац може наставити да користи своје сучеље тока са ограниченим читањима. Прокси вођен догађајима захтева модел бафера који интегрише читање унапред парсера са управљањем спремношћу. Промена временског ограничења неће помирити два независна потрошача истог сокета.

Ова дијагноза је специфична за то где се држе долазни бајтови. Након што прокси потроши исправно тело, још га мора проследити са доследним HTTP уоквиривањем. Стандардни руковалац http.server је корисно место за разумевање механизма, али није продукцијска имплементација предњег проксија.

Повезани чланци