Java-downloads via proxy wanneer getContentLengthLong -1 teruggeeft

getContentLengthLong() == -1 betekent dat er geen bekende inhoudslengte in de beschikbare metadata staat. Blijf de stream lezen en toon ontvangen bytes of onbepaalde voortgang; behandel het niet als een leeg antwoord en reserveer geen buffer met negatieve grootte.

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

De verbinding is al geconfigureerd en output is eigendom van de aanroeper. Houd verbindings- en leestime-outs en elke groottelimiet van de toepassing rond deze lus aan. Een I/O-fout is een mislukte download, geen geslaagde voltooiing met minder bytes.

Vergelijk lengtes op dezelfde laag. Chunked-codering in HTTP/1.1 kan Content-Length vervangen en wordt door de HTTP-implementatie gedecodeerd. Een proxy kan het opnieuw inkaderen. Decompressie kan er ook voor zorgen dat het gedecodeerde byteaantal van de toepassing afwijkt van een gecodeerde Content-Length.

Als zowel Transfer-Encoding als Content-Length voorkomen, kies dan geen handig getal: HTTP-framing geeft voorrang aan transfercodering en beschouwt de combinatie als een mogelijk fout. Laat die parsing aan een conforme implementatie over.

Een FTP-URL via een HTTP-gateway vereist controle van het concrete URLConnection-gedrag; het garandeert niet dat elke HTTP-header-accessor zich gedraagt als bij een gewone HTTP-URL in elke JDK. Gebruik de length-API met long-waarde waar metadata ertoe doen, en valideer het voltooide artefact tegen de lengte of checksum die daadwerkelijk vereist is. Het lezen van de body laat een eerder ontbrekende header niet verschijnen.