Java преузимања преко проксија када getContentLengthLong врати -1

getContentLengthLong() == -1 значи да у доступним метаподацима нема познате дужине садржаја. Наставите да читате ток и приказујте примљене бајтове или неодређени напредак; не третирајте то као празан одговор и не додељујте бафер негативне величине.

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

Веза је већ конфигурисана, а output поседује позивалац. Задржите временска ограничења везе и читања и било које ограничење величине апликације око ове петље. I/O грешка је неуспешно преузимање, а не успешно завршавање са мање бајтова.

Упоређујте дужине на истом слоју. HTTP/1.1 chunked кодирање може заменити Content-Length и декодира га HTTP имплементација. Прокси га може поново уоквирити. Декомпресија такође може учинити да се декодирани број бајтова апликације разликује од кодираног Content-Length.

Ако се појаве и Transfer-Encoding и Content-Length, немојте бирати згодан број: HTTP уоквиривање даје предност преносном кодирању и третира комбинацију као могућу грешку. Препустите то парсирање одговарајућој имплементацији.

FTP URL кроз HTTP гејтвеј захтева проверу конкретног понашања URLConnection; не гарантује да се сваки приступ HTTP заглављу понаша као на обичном HTTP URL-у у сваком JDK-у. Користите length API са дугом вредношћу где су метаподаци важни и валидирајте завршени артефакт према стварно потребној дужини или контролној суми. Читање тела не чини раније одсутно заглавље видљивим.