Corpos POST de um proxy HTTP em Python podem ser armazenados em rfile
Leia um pedido de proxy HTTP em Python através da entrada armazenada do handler em vez de esperar por bytes que já saíram do buffer do socket.
O proxy de encaminhamento lê a linha do pedido e os cabeçalhos, encaminha-os e depois espera em select por um corpo POST. O cliente já o enviou. Ambos os lados parecem esperar um pelo outro.
Com o BaseHTTPRequestHandler do Python, a leitura dos cabeçalhos passa por rfile, um fluxo de entrada com buffer. Esse fluxo pode ler adiantado e reter bytes que pertencem ao corpo. Esperar no socket subjacente só pergunta se o descritor de ficheiro está pronto; não pergunta se o fluxo Python já contém dados utilizáveis.
Siga o buffer que leu os cabeçalhos
Leia o corpo também através de self.rfile. Não mude para self.connection.recv depois de analisar os cabeçalhos com o fluxo com buffer. Caso contrário, o código pode ignorar bytes que esse fluxo já retém e esperar por dados que nunca serão reenviados.
Passar o próprio rfile ao select não faz o select inspecionar o seu buffer Python. A API de prontidão funciona através do descritor de ficheiro do objeto.
Para um pedido com um Content-Length válido e sem Transfer-Encoding, consuma exatamente o número de bytes declarado, tratando do fim prematuro da entrada e dos seus limites de tamanho e tempo. Não leia até EOF: um cliente com ligação persistente pode manter a ligação aberta depois de terminar o pedido.
Torne o enquadramento uma parte explícita do proxy
Corpos de pedido chunked precisam de suporte de enquadramento chunked. Não podem ser lidos procurando um Content-Length ausente. Metadados de comprimento ambíguos precisam de um caminho de rejeição definido, em vez de escolher o cabeçalho que parece conveniente.
Um handler bloqueante pode continuar a usar a sua interface de fluxo com leituras limitadas. Um proxy orientado a eventos precisa de um modelo de buffer que integre a leitura adiantada do analisador com o tratamento de prontidão. Alterar um timeout não reconciliará dois consumidores independentes do mesmo socket.
Este diagnóstico é específico de onde os bytes de entrada são retidos. Depois de o proxy consumir o corpo correto, ainda precisa de o encaminhar com um enquadramento HTTP consistente. O handler padrão http.server é um local útil para compreender o mecanismo, mas não é uma implementação de proxy de encaminhamento para produção.