Java-niðurtøkur gjøgnum proxy tá getContentLengthLong letur -1 aftur

getContentLengthLong() == -1 merkir, at ongin kend innihaldslongd er í tøkum metadátum. Halt fram at lesa streymin og vís mótteknar bætur ella óvissan framgongd; met tað ikki sum eitt tómt svar og set ikki av ein buffer við negativari stødd.

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

Sambandið er longu sett upp og output eigur kallarin. Halt sambands og lesitíðarmørk og eina støddarmark hjá forritinum uttan um hesa lykkju. Ein I/O-villa er ein miseydnað niðurtøka, ikki eydnukend avslutning við færri bætum.

Samanber longdir á somu stigi. Chunked-kóðing í HTTP/1.1 kann taka staðin fyri Content-Length og verður avkóðað av HTTP-útførsluni. Ein proxy kann seta tað upp aftur. Dekompression kann eisini gera avkóðaða bættalið hjá forritinum øðrvísi enn eitt kóðað Content-Length.

Um bæði Transfer-Encoding og Content-Length eru til staðar, vel ikki eitt hóskiligt tal: HTTP-ramma setur flutningskóðing í fremstu røð og metur samansetingina sum eina møguliga villu. Lat ta greiningina vera hjá einari samsvarandi útførslu.

Ein FTP-URL gjøgnum eina HTTP-gátt krevur, at hin konkreta URLConnection-atferðin verður kannað; tað tryggjar ikki, at hvør HTTP-høvdar-atgong ber seg at sum á einari vanligari HTTP-URL í hvørjari JDK. Brúka length-API-ið við long-virði har metadáta telja, og vátta tað liðuga artifaktið móti tí longd ella checksum, sum veruliga er kravd. At lesa kropsins ger ikki eitt fyrr manglandi høvd at koma fyri seg.