Java-downloads via proxy, når getContentLengthLong returnerer -1

getContentLengthLong() == -1 betyder, at der ikke er nogen kendt indholdslængde i de tilgængelige metadata. Fortsæt med at læse strømmen, og vis modtagne bytes eller ubestemt fremdrift; behandl det ikke som et tomt svar, og tildel ikke en buffer med negativ størrelse.

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;
    }
}

Forbindelsen er allerede konfigureret, og output ejes af kalderen. Behold forbindelses- og læsetimeouts samt enhver størrelsesgrænse i applikationen omkring denne løkke. En I/O-fejl er en mislykket download, ikke en vellykket afslutning med færre bytes.

Sammenlign længder på samme lag. HTTP/1.1 chunked-kodning kan erstatte Content-Length og afkodes af HTTP-implementeringen. En proxy kan omramme den. Dekomprimering kan også gøre applikationens afkodede byteantal forskelligt fra en kodet Content-Length.

Hvis både Transfer-Encoding og Content-Length optræder, må du ikke vælge et bekvemt tal: HTTP-rammer giver transfer-kodning forrang og behandler kombinationen som en mulig fejl. Overlad den parsing til en compliant implementering.

En FTP-URL gennem en HTTP-gateway kræver, at dens konkrete URLConnection-adfærd kontrolleres; den garanterer ikke, at hver HTTP-header-adgang opfører sig som på en almindelig HTTP-URL i enhver JDK. Brug length-API'et med lang værdi, hvor metadata betyder noget, og valider det færdige artefakt mod den længde eller checksum, der faktisk kræves. At læse body får ikke en tidligere fraværende header til at dukke op.