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 շրջանակավորումը առաջնահերթություն է տալիս փոխանցման կոդավորմանը և համակցությունը համարում է հնարավոր սխալ։ Թողեք այդ վերլուծությունը համապատասխան իրականացմանը։

HTTP դարպասի միջոցով FTP URL-ը պահանջում է ստուգել դրա կոնկրետ URLConnection վարքը. այն չի երաշխավորում, որ յուրաքանչյուր HTTP վերնագրի հասանելիք իրեն պահում է ինչպես սովորական HTTP URL-ի դեպքում յուրաքանչյուր JDK-ում։ Օգտագործեք երկար արժեքով length API-ն այնտեղ, որտեղ մետատվյալները կարևոր են, և ստուգեք ավարտված արտեֆակտը փաստացի պահանջվող երկարության կամ ստուգիչ գումարի դեմ։ Մարմինը կարդալը նախկինում բացակայող վերնագիր չի հայտնում։