Ler a subida por anacos non require HTTP fragmentado
Separe as lecturas acoutadas da aplicación do entramado de mensaxes HTTP/1.1 cando unha subida se comporta distinto a través dun proxy de saída.
Non. Un cliente pode ler un ficheiro grande en memorias intermedias pequenas e envialo cun Content-Length coñecido. As lecturas acoutadas controlan o uso de memoria; o entramado HTTP indica ao receptor onde remata o corpo da petición.
Un ficheiro estable cuxa lonxitude en bytes coñece a biblioteca HTTP é distinto dun xerador que produce unha cantidade descoñecida de datos. Use a interface de corpo admitida pola biblioteca para calquera das dúas fontes. Non cómpre montar todo o ficheiro nunha cadea só para proporcionar unha lonxitude.
Para HTTP/1.1, inspeccione o entramado realmente enviado: Content-Length ou codificación de transferencia fragmentada segundo as regras do protocolo. A codificación fragmentada engade marcadores de tamaño fóra do contido do ficheiro. Non combine campos de entramado contraditorios nin adiviñe unha lonxitude para convencer un proxy de que acepte a subida.
Se unha subida a través dun proxy falla, anote a versión de HTTP, a orixe do corpo e o primeiro rexeitamento. Unha resposta 411 suxire unha investigación distinta da dunha conexión que se pecha a metade do corpo. Se en cambio fallan os reintentos de autenticación, comprobe se o corpo da subida se pode reproducir. Cambiar o tamaño do búfer de lectura da aplicación pode deixar o entramado da petición exactamente como estaba.
A ruta importa para esa observación. O reenvío en texto claro expón o entramado HTTP da subida ao proxy; un HTTPS normal de extremo a extremo colócao dentro dun túnel. HTTP/2 usa o seu propio entramado. Por iso as limitacións históricas de Squid explican fallos antigos concretos, non unha regra de que todo proxy actual rexeite as subidas en fluxo.