getContentLengthLong -1 кайтарганда Java прокси аркылуу жүктөөлөр

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 алкактары транспорттук коддоого артыкчылык берет жана айкалышты мүмкүн болгон ката деп эсептейт. Бул талдоону ылайыктуу ишке ашырууга калтырыңыз.

HTTP шлюзи аркылуу FTP URL анын конкреттүү URLConnection жүрүм-турумун текшерүүнү талап кылат; ал ар бир JDK'де ар бир HTTP аталыш кирүүсү кадимки HTTP URL сыяктуу жүрүм-турум көрсөтөт деп кепилдик бербейт. Метаберилиштер маанилүү жерде узун маанидеги length API колдонуңуз жана бүткөн артефактты чындап талап кылынган узундук же текшерүү суммасы менен текшериңиз. Денени окуу мурун жок болгон аталышты пайда кылбайт.