Sťahovania Java cez proxy, keď getContentLengthLong vracia -1
Spracujte neznámy Content-Length pri sťahovaní cez proxy bez toho, aby ste chýbajúce metadáta o veľkosti považovali za prázdnu odpoveď.
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í.