Těla POST v HTTP proxy na Pythonu lze ukládat do rfile

Dopředný proxy přečte řádek požadavku a hlavičky, přepošle je a pak v select čeká na tělo POST. Klient ho už odeslal. Obě strany vypadají, že čekají jedna na druhou.

U BaseHTTPRequestHandler v Pythonu čtení hlaviček prochází přes rfile, bufferovaný vstupní proud. Ten proud může číst dopředu a držet bajty patřící tělu. Čekání na podkladový socket se ptá jen, zda je jeho deskriptor souboru připraven; neptá se, zda proud Pythonu už obsahuje použitelná data.

Následujte buffer, který přečetl hlavičky

Čtěte tělo také přes self.rfile. Nepřepínejte na self.connection.recv poté, co jste hlavičky zpracovali bufferovaným proudem. Jinak kód může obejít bajty, které proud už drží, a čekat na data, která už nikdy nebudou odeslána.

Předání samotného rfile do select nezpůsobí, že select prohlédne jeho buffer v Pythonu. API připravenosti pracuje přes deskriptor souboru objektu.

U požadavku s jedním platným Content-Length a bez Transfer-Encoding spotřebujte přesně deklarovaný počet bajtů, ošetřete předčasný konec vstupu i svá omezení velikosti a času. Nečtěte do EOF: klient s trvalým připojením může po dokončení požadavku nechat připojení otevřené.

Udělejte z rámování explicitní součást proxy

Chunked těla požadavků potřebují podporu chunked rámování. Nelze je číst hledáním chybějícího Content-Length. Nejednoznačná metadata délky potřebují definovanou cestu odmítnutí, místo volby hlavičky, která se zdá pohodlná.

Blokující handler může dál používat své rozhraní proudu s omezeným čtením. Proxy řízený událostmi potřebuje model bufferu, který integruje předběžné čtení parseru se správou připravenosti. Změna časového limitu nesmíří dva nezávislé konzumenty téhož socketu.

Tato diagnóza se týká toho, kde jsou příchozí bajty drženy. Jakmile proxy spotřebuje správné tělo, stále ho musí přeposlat s konzistentním HTTP rámováním. Standardní handler http.server je užitečné místo pro pochopení mechanismu, ale není produkční implementací dopředného proxy.