Java-downloads fia proxy as getContentLengthLong -1 weromjout

getContentLengthLong() == -1 betsjut dat der gjin bekende ynhâldslings is yn de beskikbere metadata. Gean troch mei it lêzen fan de stream en lit ûntfongen bytes of ûnbepaalde foarútgong sjen; behannelje it net as in leech antwurd en allokearje gjin buffer mei negative grutte.

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 ferbining is al konfigurearre en output is fan de oanropper. Hâld ferbinings- en lêstiidlimiters en elke gruttelimyt fan de applikaasje om dizze lus hinne. In I/O-flater is in mislearre download, net in suksesfolle foltôging mei minder bytes.

Fergelykje lingtes op deselde laach. Chunked-kodearring fan HTTP/1.1 kin Content-Length ferfange en wurdt dekodearre troch de HTTP-ymplemintaasje. In proxy kin it opnij ramje. Dekompresje kin ek meitsje dat it dekodearre bytetel fan de applikaasje oars is as in kodearre Content-Length.

As sawol Transfer-Encoding as Content-Length foarkomme, kies dan gjin handich getal: HTTP-ramjen jout foarrang oan transferkodearring en behannelet de kombinaasje as in mooglike flater. Lit dy ûntleding oan in foldogge ymplemintaasje oer.

In FTP-URL fia in HTTP-gateway freget om kontrôle fan it konkrete URLConnection-gedrach; it garandearret net dat elke HTTP-kopteksttagong him hâldt en draacht as by in gewoane HTTP-URL yn elke JDK. Brûk de lingte-API mei lange wearde wêr't metadata ta docht, en falidearje it foltôge artefakt tsjin de lingte of checksum dy't eins fereaske is. It lêzen fan it lichem lit in earder ûntbrekkende koptekst net ferskine.