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 प्रयोग गर्नुहोस्, र पूरा भएको आर्टिफ्याक्टलाई वास्तवमा आवश्यक लम्बाई वा चेकसमसँग प्रमाणित गर्नुहोस्। बडी पढ्नाले पहिले अनुपस्थित हेडर देखा पर्दैन।