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 грешка е неуспешно преземање, а не успешно завршување со помалку бајти.

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

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

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