Descargas de Java a través de proxy cuando getContentLengthLong devuelve -1

getContentLengthLong() == -1 significa que no hay una longitud de contenido conocida en los metadatos disponibles. Sigue leyendo el flujo y muestra los bytes recibidos o un progreso indeterminado; no lo trates como una respuesta vacía ni asignes un búfer de tamaño negativo.

long expected = connection.getContentLengthLong();
long received = 0;
byte[] buffer = new byte[8192];
try (InputStream input = connection.getInputStream()) {
    int count;
    while ((count = input.read(buffer)) != -1) {
        output.write(buffer, 0, count);
        received += count;
    }
}

La conexión ya está configurada y el llamador es dueño de output. Mantén los tiempos de espera de conexión y lectura y cualquier límite de tamaño de la aplicación en torno a este bucle. Un error de E/S es una descarga fallida, no una finalización correcta con menos bytes.

Compara longitudes en la misma capa. La codificación chunked de HTTP/1.1 puede sustituir Content-Length y la decodifica la implementación HTTP. Un proxy puede reencuadrarla. La descompresión también puede hacer que el recuento de bytes decodificados de la aplicación difiera de un Content-Length codificado.

Si aparecen tanto Transfer-Encoding como Content-Length, no elijas un número conveniente: el encuadre HTTP da prioridad a la codificación de transferencia y trata la combinación como un posible error. Deja ese análisis a una implementación conforme.

Una URL FTP a través de una pasarela HTTP requiere comprobar el comportamiento concreto de URLConnection; no garantiza que cada acceso a cabecera HTTP se comporte como en una URL HTTP ordinaria en todas las JDK. Usa la API de longitud con valor largo donde importen los metadatos y valida el artefacto completado contra la longitud o la suma de comprobación realmente requeridas. Leer el cuerpo no hace que aparezca una cabecera que antes faltaba.