Leer la subida por trozos no requiere HTTP fragmentado
Separe las lecturas acotadas de la aplicación del entramado de mensajes HTTP/1.1 cuando una subida se comporta de forma distinta a través de un proxy directo.
No. Un cliente puede leer un archivo grande en búferes pequeños y enviarlo con un Content-Length conocido. Las lecturas acotadas controlan el uso de memoria; el entramado HTTP indica al receptor dónde termina el cuerpo de la petición.
Un archivo estable cuya longitud en bytes conoce la biblioteca HTTP es distinto de un generador que produce una cantidad desconocida de datos. Use la interfaz de cuerpo que admita la biblioteca para cualquiera de las dos fuentes. No hace falta ensamblar todo el archivo en una cadena solo para proporcionar una longitud.
Para HTTP/1.1, inspeccione el entramado realmente enviado: Content-Length o codificación de transferencia fragmentada según las reglas del protocolo. La codificación fragmentada añade marcadores de tamaño fuera del contenido del archivo. No combine campos de entramado contradictorios ni adivine una longitud para convencer a un proxy de que acepte la subida.
Si una subida que pasa por un proxy falla, anote la versión de HTTP, el origen del cuerpo y el primer rechazo. Una respuesta 411 sugiere una investigación distinta de una conexión que se cierra a mitad del cuerpo. Si en cambio fallan los reintentos de autenticación, compruebe si el cuerpo de la subida se puede reproducir. Cambiar el tamaño del búfer de lectura de la aplicación puede dejar el entramado de la petición exactamente como estaba.
La ruta importa para esa observación. El reenvío en texto claro expone el entramado HTTP de la subida al proxy; un HTTPS normal de extremo a extremo lo coloca dentro de un túnel. HTTP/2 usa su propio entramado. Por eso las limitaciones históricas de Squid explican fallos antiguos concretos, no una regla de que todo proxy actual rechace las subidas en flujo.