Java-nedlastinger via proxy når getContentLengthLong returnerer -1

getContentLengthLong() == -1 betyr at det ikke finnes noen kjent innholdslengde i metadataene som er tilgjengelige. Fortsett å lese strømmen og vis mottatte byte eller ubestemt fremdrift; ikke behandle det som et tomt svar og ikke tilordne 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;
    }
}

Tilkoblingen er allerede konfigurert, og output eies av den som kaller. Behold tidsavbrudd for tilkobling og lesing samt eventuell størrelsesgrense i applikasjonen rundt denne løkken. En I/O-feil er en mislykket nedlasting, ikke en vellykket fullføring med færre byte.

Sammenlign lengder på samme lag. Chunked-koding i HTTP/1.1 kan erstatte Content-Length og dekodes av HTTP-implementasjonen. En proxy kan ramme det inn på nytt. Dekomprimering kan også gjøre at applikasjonens dekodede byteantall avviker fra en kodet Content-Length.

Hvis både Transfer-Encoding og Content-Length forekommer, ikke velg et bekvemt tall: HTTP-ramming gir overføringskoding forrang og behandler kombinasjonen som en mulig feil. Overlat den parsingen til en samsvarende implementasjon.

En FTP-URL gjennom en HTTP-gateway krever at den konkrete URLConnection-oppførselen kontrolleres; den garanterer ikke at hver HTTP-header-tilgang oppfører seg som på en vanlig HTTP-URL i enhver JDK. Bruk length-API-et med lang verdi der metadata betyr noe, og valider det ferdige artefaktet mot lengden eller sjekksummen som faktisk kreves. Å lese kroppen får ikke en tidligere fraværende header til å dukke opp.