Los cuerpos POST de un proxy HTTP en Python pueden almacenarse en rfile
Lee una solicitud de proxy HTTP en Python a través de la entrada almacenada del manejador en lugar de esperar bytes que ya salieron del búfer del socket.
El proxy de reenvío lee la línea de solicitud y las cabeceras, las reenvía y luego espera en select un cuerpo POST. El cliente ya lo ha enviado. Ambos lados parecen estar esperando al otro.
Con BaseHTTPRequestHandler de Python, la lectura de las cabeceras pasa por rfile, un flujo de entrada con búfer. Ese flujo puede leer por adelantado y retener bytes que pertenecen al cuerpo. Esperar en el socket subyacente solo pregunta si su descriptor de archivo está listo; no pregunta si el flujo de Python ya contiene datos utilizables.
Sigue el búfer que leyó las cabeceras
Lee el cuerpo también a través de self.rfile. No cambies a self.connection.recv después de analizar las cabeceras con el flujo con búfer. De lo contrario, el código puede omitir bytes que ese flujo ya retiene y esperar datos que nunca se volverán a enviar.
Pasar rfile mismo a select no hace que select inspeccione su búfer de Python. La API de disponibilidad funciona a través del descriptor de archivo del objeto.
Para una solicitud con un Content-Length válido y sin Transfer-Encoding, consume exactamente el número de bytes declarado, manejando el final prematuro de la entrada y tus límites de tamaño y tiempo. No leas hasta EOF: un cliente con conexión persistente puede mantener la conexión abierta después de terminar la solicitud.
Haz del encuadre una parte explícita del proxy
Los cuerpos de solicitud fragmentados necesitan soporte de encuadre fragmentado. No se pueden leer buscando un Content-Length ausente. Los metadatos de longitud ambiguos necesitan una ruta de rechazo definida, en lugar de elegir la cabecera que parezca conveniente.
Un manejador bloqueante puede seguir usando su interfaz de flujo con lecturas acotadas. Un proxy dirigido por eventos necesita un modelo de búfer que integre la lectura anticipada del analizador con la gestión de disponibilidad. Cambiar un tiempo de espera no reconciliará a dos consumidores independientes del mismo socket.
Este diagnóstico es específico de dónde se retienen los bytes entrantes. Una vez que el proxy ha consumido el cuerpo correcto, todavía necesita reenviar ese cuerpo con un encuadre HTTP coherente. El manejador estándar http.server es un lugar útil para entender el mecanismo, pero no es una implementación de proxy de reenvío para producción.