Ler o upload em partes não exige HTTP chunked
Separe as leituras limitadas da aplicação do enquadramento de mensagens HTTP/1.1 quando um upload se comporta de forma diferente através de um proxy de encaminhamento.
Não. Um cliente pode ler um arquivo grande em buffers pequenos e enviá-lo com um Content-Length conhecido. Leituras limitadas controlam o uso de memória; o enquadramento HTTP informa ao destinatário onde termina o corpo da requisição.
Um arquivo estável cujo comprimento em bytes a biblioteca HTTP conhece é diferente de um gerador que produz uma quantidade desconhecida de dados. Use a interface de corpo suportada pela biblioteca para as duas fontes. Não é preciso montar o arquivo inteiro numa string apenas para fornecer um comprimento.
Para HTTP/1.1, inspecione o enquadramento realmente enviado: Content-Length ou codificação de transferência chunked conforme as regras do protocolo. A codificação chunked adiciona marcadores de tamanho fora do conteúdo do arquivo. Não combine campos de enquadramento contraditórios nem adivinhe um comprimento para convencer um proxy a aceitar o upload.
Se um upload através de um proxy falhar, registre a versão HTTP, a origem do corpo e a primeira rejeição. Uma resposta 411 sugere uma investigação diferente de uma conexão que se fecha no meio do corpo. Se em vez disso falharem as novas tentativas de autenticação, verifique se o corpo do upload pode ser reproduzido. Alterar o tamanho do buffer de leitura da aplicação pode deixar o enquadramento da requisição exatamente como estava.
A rota importa para essa observação. O encaminhamento em texto simples expõe o enquadramento HTTP do upload ao proxy; o HTTPS comum de ponta a ponta coloca-o dentro de um túnel. O HTTP/2 usa o seu próprio enquadramento. Por isso, as limitações históricas do Squid explicam falhas antigas específicas, não uma regra de que todo proxy atual rejeita uploads em fluxo.