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 URL-এর মতো প্রতিটি HTTP হেডার অ্যাক্সেসরের আচরণের নিশ্চয়তা দেয় না। যেখানে মেটাডেটা গুরুত্বপূর্ণ সেখানে দীর্ঘ-মানের length API ব্যবহার করুন, এবং সম্পূর্ণ হওয়া আর্টিফ্যাক্টকে প্রকৃতপক্ষে প্রয়োজনীয় দৈর্ঘ্য বা চেকসামের বিরুদ্ধে যাচাই করুন। বডি পড়লে আগে অনুপস্থিত হেডার দেখা যায় না।