Descargas de Java a través de proxy cando getContentLengthLong devolve -1

getContentLengthLong() == -1 significa que non hai unha lonxitude de contido coñecida nos metadatos dispoñibles. Segue lendo o fluxo e mostra os bytes recibidos ou un progreso indeterminado; non o trates como unha resposta baleira nin 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;
    }
}

A conexión xa está configurada e o chamador é dono de output. Mantén os tempos de espera de conexión e lectura e calquera límite de tamaño da aplicación arredor deste bucle. Un erro de E/S é unha descarga fallida, non unha finalización correcta con menos bytes.

Compara lonxitudes na mesma capa. A codificación chunked de HTTP/1.1 pode substituír Content-Length e é decodificada pola implementación HTTP. Un proxy pode reencadrala. A descompresión tamén pode facer que a conta de bytes decodificados da aplicación difira dun Content-Length codificado.

Se aparecen tanto Transfer-Encoding como Content-Length, non escollas un número cómodo: o encadramento HTTP dá prioridade á codificación de transferencia e trata a combinación como un posible erro. Deixa esa análise a unha implementación conforme.

Un URL FTP a través dunha pasarela HTTP require comprobar o comportamento concreto de URLConnection; non garante que cada acceso a cabeceira HTTP se comporte como nun URL HTTP ordinario en todos os JDK. Usa a API de lonxitude con valor longo onde importan os metadatos e valida o artefacto completado contra a lonxitude ou a suma de comprobación realmente requiridas. Ler o corpo non fai que apareza unha cabeceira que antes faltaba.