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 სადაც მეტამონაცემები მნიშვნელოვანია, და შეამოწმეთ დასრულებული არტეფაქტი რეალურად საჭირო სიგრძის ან საკონტროლო ჯამის მიმართ. სხეულის კითხვა ადრე არარსებულ თავსართს არ აჩენს.