getContentLengthLong() == -1 znamená, že v dostupných metadátach nie je známa dĺžka obsahu. Pokračujte v čítaní streamu a zobrazujte prijaté bajty alebo neurčitý priebeh; nepovažujte to za prázdnu odpoveď a nealokujte buffer so zápornou veľkosťou.

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

Pripojenie je už nakonfigurované a output vlastní volajúci. Zachovajte časové limity pripojenia a čítania a prípadný limit veľkosti aplikácie okolo tejto slučky. I/O chyba je neúspešné stiahnutie, nie úspešné dokončenie s menším počtom bajtov.

Porovnávajte dĺžky na rovnakej vrstve. Chunked kódovanie HTTP/1.1 môže nahradiť Content-Length a dekóduje ho implementácia HTTP. Proxy ho môže prerámovať. Dekompresia tiež môže spôsobiť, že dekódovaný počet bajtov aplikácie sa líši od zakódovaného Content-Length.

Ak sa vyskytnú Transfer-Encoding aj Content-Length, nevyberajte pohodlné číslo: rámovanie HTTP dáva prednosť prenosovému kódovaniu a kombináciu považuje za možnú chybu. Nechajte toto parsovanie na zodpovedajúcu implementáciu.

URL FTP cez HTTP bránu vyžaduje overenie konkrétneho správania URLConnection; nezaručuje, že sa každý prístup k HTTP hlavičke správa ako na bežnej HTTP URL v každom JDK. Kde záleží na metadátach, použite length API s dlhou hodnotou, a overte dokončený artefakt voči skutočne požadovanej dĺžke alebo kontrolnému súčtu. Prečítanie tela nespôsobí, že sa predtým chýbajúca hlavička objaví.

Súvisiace články