Os corpos POST dun proxy HTTP de Python pódense almacenar en rfile
Le unha solicitude de proxy HTTP de Python a través da entrada almacenada do manexador en lugar de esperar bytes que xa saíron do búfer do socket.
O proxy directo le a liña de solicitude e as cabeceiras, reenvíaas e despois espera en select un corpo POST. O cliente xa o enviou. Ambos os lados parecen estar esperando polo outro.
Con BaseHTTPRequestHandler de Python, a lectura das cabeceiras pasa por rfile, un fluxo de entrada con búfer. Ese fluxo pode ler por adiantado e reter bytes que pertencen ao corpo. Esperar no socket subxacente só pregunta se o seu descriptor de ficheiro está listo; non pregunta se o fluxo de Python xa contén datos utilizables.
Segue o búfer que leu as cabeceiras
Le o corpo tamén a través de self.rfile. Non cambies a self.connection.recv despois de analizar as cabeceiras co fluxo con búfer. Se non, o código pode omitir bytes que ese fluxo xa retén e esperar datos que nunca se volverán enviar.
Pasar rfile mesmo a select non fai que select inspeccione o seu búfer de Python. A API de dispoñibilidade funciona a través do descriptor de ficheiro do obxecto.
Para unha solicitude cun Content-Length válido e sen Transfer-Encoding, consume exactamente o número de bytes declarado, manexando o final prematuro da entrada e os teus límites de tamaño e tempo. Non leas ata EOF: un cliente cunha conexión persistente pode manter a conexión aberta despois de rematar a solicitude.
Fai do enmarcado unha parte explícita do proxy
Os corpos de solicitude fragmentados necesitan soporte de enmarcado fragmentado. Non se poden ler buscando un Content-Length ausente. Os metadatos de lonxitude ambiguos necesitan unha ruta de rexeitamento definida, en lugar de escoller a cabeceira que pareza conveniente.
Un manexador bloqueante pode seguir usando a súa interface de fluxo con lecturas limitadas. Un proxy dirixido por eventos necesita un modelo de búfer que integre a lectura anticipada do analizador coa xestión da dispoñibilidade. Cambiar un tempo de espera non reconciliará dous consumidores independentes do mesmo socket.
Este diagnóstico é específico de onde se reteñen os bytes entrantes. Unha vez que o proxy consumiu o corpo correcto, aínda necesita reenviar ese corpo cun enmarcado HTTP coherente. O manexador estándar http.server é un lugar útil para entender o mecanismo, pero non é unha implementación de proxy directo de produción.