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

Handter ein ukjend Content-Length i ei Java-nedlasting via proxy utan å handsame manglande storleiksmetadata som eit tomt svar.

getContentLengthLong() == -1 tyder at det ikkje finst noka kjend innhaldslengd i metadataa som er tilgjengelege. Hald fram med å lese straumen og vis mottekne byte eller ubestemd framdrift; handsam det ikkje som eit tomt svar og tildel ikkje ein buffer med negativ storleik.

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

Tilkoplinga er alt konfigurert, og output eigast av den som kallar. Hald på tidsavbrot for tilkopling og lesing samt eventuell storleiksgrense i applikasjonen rundt denne løkka. Ein I/O-feil er ei mislukka nedlasting, ikkje ei vellukka fullføring med færre byte.

Samanlikn lengder på same lag. Chunked-koding i HTTP/1.1 kan erstatte Content-Length og vert dekoda av HTTP-implementasjonen. Ein proxy kan ramme det inn på nytt. Dekomprimering kan òg gjere at det dekoda byteantalet i applikasjonen avvik frå ein koda Content-Length.

Viss både Transfer-Encoding og Content-Length finst, vel ikkje eit høveleg tal: HTTP-ramming gir overføringskoding forrang og handsamar kombinasjonen som ein mogeleg feil. Overlat den parsings til ein samsvarande implementasjon.

Ein FTP-URL gjennom ein HTTP-gateway krev at den konkrete URLConnection-åtferda vert kontrollert; han garanterer ikkje at kvar HTTP-header-tilgang oppfører seg som på ein vanleg HTTP-URL i kvar JDK. Bruk length-API-et med lang verdi der metadata tel, og valider det ferdige artefaktet mot lengda eller sjekksummen som faktisk krevst. Å lese kroppen får ikkje ein tidlegare fråverande header til å dukke opp.

Relaterte artiklar