Stahování přes Java proxy, když getContentLengthLong vrací -1

Zpracujte neznámý Content-Length při stahování přes proxy, aniž byste chybějící metadata o velikosti považovali za prázdnou odpověď.

getContentLengthLong() == -1 znamená, že v dostupných metadatech není známa délka obsahu. Pokračujte ve čtení streamu a zobrazujte přijaté bajty nebo neurčitý průběh; nepovažujte to za prázdnou odpověď a nealokujte buffer se zápornou velikostí.

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

Spojení je již nakonfigurováno a output vlastní volající. Zachovejte časové limity spojení a čtení a případný limit velikosti aplikace kolem této smyčky. I/O chyba je neúspěšné stažení, nikoli úspěšné dokončení s menším počtem bajtů.

Porovnávejte délky na stejné vrstvě. Chunked kódování HTTP/1.1 může nahradit Content-Length a dekóduje ho implementace HTTP. Proxy ho může přerámovat. Dekomprese také může způsobit, že dekódovaný počet bajtů aplikace se liší od zakódovaného Content-Length.

Pokud se objeví Transfer-Encoding i Content-Length, nevybírejte pohodlné číslo: rámování HTTP dává přednost přenosovému kódování a kombinaci považuje za možnou chybu. Nechte toto parsování na odpovídající implementaci.

URL FTP přes HTTP bránu vyžaduje ověření konkrétního chování URLConnection; nezaručuje, že se každý přístup k HTTP hlavičce chová jako u běžné HTTP URL v každém JDK. Kde záleží na metadatech, použijte length API s dlouhou hodnotou, a ověřte dokončený artefakt proti skutečně požadované délce nebo kontrolnímu součtu. Přečtení těla nezpůsobí, že se dříve chybějící hlavička objeví.

Související články