Java-elŝutaĵoj per prokuro kiam getContentLengthLong redonas -1

getContentLengthLong() == -1 signifas, ke ne ekzistas konata enhava longo en la disponebla metadateno. Daŭrigu legi la fluon kaj montru ricevitajn bitokojn aŭ nedifinitan progreson; ne traktu ĝin kiel malplenan respondon kaj ne asignu bufron de negativa grando.

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

La konekto jam estas agordita kaj output apartenas al la alvokanto. Konservu la konektajn kaj legajn tempolimojn kaj ajnan grandecan limon de la aplikaĵo ĉirkaŭ ĉi tiu buklo. Eniga/eliga eraro estas malsukcesa elŝuto, ne sukcesa finiĝo kun malpli da bitokoj.

Komparu longojn je la sama tavolo. La chunked-kodado de HTTP/1.1 povas anstataŭigi Content-Length kaj estas malĉifrata de la HTTP-realigo. Prokuro povas reenradzigi ĝin. Ankaŭ maldensigo povas igi la malĉifritan bitokkvanton de la aplikaĵo malsama ol ĉifrita Content-Length.

Se aperas kaj Transfer-Encoding kaj Content-Length, ne elektu oportun numeron: HTTP-enkadrigo donas prioritaton al la transporta kodado kaj traktas la kombinaĵon kiel eblan eraron. Lasu tiun analizon al konforma realigo.

FTP-URL tra HTTP-pordego bezonas kontrolon de sia konkreta URLConnection-konduto; ĝi ne garantias, ke ĉiu HTTP-kapara alirilo kondutas kiel ĉe ordinara HTTP-URL en ĉiu JDK. Uzu la longvaloran length-API kie metadateno gravas, kaj validigu la finitan artefakton kontraŭ la efektive postulata longo aŭ kontrolsumo. Legi la korpon ne igas antaŭe mankantan kapon aperi.