Java-niðurhal í gegnum proxy þegar getContentLengthLong skilar -1

getContentLengthLong() == -1 þýðir að engin þekkt innihandslengd er í tiltækum lýsigögnum. Haltu áfram að lesa strauminn og sýndu mótteknar bætur eða óákveðinn framgang; ekki líta á það sem tómt svar og ekki úthluta biðminni með neikvæðri stærð.

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

Tengingin er þegar stillt og output er í eigu kallarans. Haltu tengi- og lestrartímatökum og hvaða stærðarmörkum forritsins sem er í kringum þessa lykkju. I/O-villa er misheppnað niðurhal, ekki árangursrík lok með færri bætum.

Berðu saman lengdir á sama lagi. Chunked-kóðun í HTTP/1.1 getur komið í stað Content-Length og er afkóðuð af HTTP-útfærslunni. Proxy getur endurrammað hana. Afþjöppun getur líka valdið því að afkóðað bætatal forritsins sé frábrugðið kóðuðu Content-Length.

Ef bæði Transfer-Encoding og Content-Length koma fram, veldu ekki þægilega tölu: HTTP-ramma setur flutningskóðun í forgang og lítur á samsetninguna sem mögulega villu. Láttu þá þáttun vera hjá samhæfðri útfærslu.

FTP-vefslóð í gegnum HTTP-gátt krefst þess að skoðað sé hvernig URLConnection hagar sér í reynd; hún ábyrgist ekki að hver HTTP-hausaaðgangur hagi sér eins og á venjulegri HTTP-vefslóð í hverri JDK. Notaðu length-API með löngu gildi þar sem lýsigögn skipta máli, og staðfestu fullunnu gripinn gegn lengdinni eða tætunarsummunni sem raunverulega er krafist. Að lesa búkinn lætur ekki haus sem vantaði áður birtast.