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 व्यवहार जाँचना ज़रूरी है; यह गारंटी नहीं देता कि हर HTTP हेडर एक्सेसर हर JDK में सामान्य HTTP URL जैसा व्यवहार करे। जहाँ मेटाडेटा मायने रखता है वहाँ लंबे मान वाला length API इस्तेमाल करें, और पूर्ण हुए आर्टिफ़ैक्ट को वास्तव में आवश्यक लंबाई या चेकसम के विरुद्ध सत्यापित करें। बॉडी पढ़ने से पहले अनुपस्थित हेडर प्रकट नहीं होता।