Тіла POST в HTTP-проксі на Python можуть буферизуватися в rfile
Читайте запит HTTP-проксі на Python через буферизований ввід обробника, а не чекайте на байти, які вже залишили буфер сокета.
Прямий проксі читає рядок запиту й заголовки, пересилає їх, а потім чекає в 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 — корисне місце для розуміння механізму, але це не виробнича реалізація прямого проксі.