Ang getContentLengthLong() == -1 ay nangangahulugang walang kilalang haba ng nilalaman sa magagamit na metadata. Ipagpatuloy ang pagbasa ng stream at ipakita ang mga natanggap na byte o hindi tiyak na pag-unlad; huwag ituring na walang laman na tugon at huwag maglaan ng buffer na may negatibong sukat.

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

Naka-configure na ang koneksyon at pagmamay-ari ng tumatawag ang output. Panatilihin ang mga timeout ng koneksyon at pagbasa at anumang limitasyon sa sukat ng aplikasyon sa paligid ng loop na ito. Ang error sa I/O ay bigong pag-download, hindi matagumpay na pagkumpleto na may mas kaunting byte.

Ihambing ang mga haba sa parehong layer. Ang chunked encoding ng HTTP/1.1 ay maaaring pumalit sa Content-Length at ito ay dine-decode ng implementasyon ng HTTP. Maaaring muling i-frame ito ng proxy. Ang decompression ay maaari ring gawing iba ang na-decode na bilang ng byte ng aplikasyon mula sa naka-encode na Content-Length.

Kung parehong lumitaw ang Transfer-Encoding at Content-Length, huwag pumili ng maginhawang numero: binibigyan ng HTTP framing ng priyoridad ang transfer coding at itinuturing ang kombinasyon na posibleng error. Ipaubaya ang pag-parse na iyon sa isang umaayon na implementasyon.

Ang URL ng FTP sa pamamagitan ng gateway ng HTTP ay nangangailangan ng pagsuri sa konkretong pag-uugali ng URLConnection; hindi nito ginagarantiyahan na ang bawat accessor ng header ng HTTP ay kikilos tulad ng sa ordinaryong URL ng HTTP sa bawat JDK. Gamitin ang length API na may mahabang halaga kung saan mahalaga ang metadata, at i-validate ang natapos na artifact laban sa haba o checksum na aktuwal na kailangan. Ang pagbasa ng body ay hindi nagpapalitaw ng header na dating wala.

Kaugnay na mga artikulo