getContentLengthLong -1 परत करतो तेव्हा Java प्रॉक्सी डाउनलोड

प्रॉक्सीद्वारे Java डाउनलोडमध्ये अज्ञात Content-Length हाताळा, अनुपस्थित आकार मेटाडेटा रिकामा प्रतिसाद मानू नका.

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 वापरा, आणि पूर्ण झालेल्या आर्टिफॅक्टची प्रत्यक्षात आवश्यक लांबी किंवा चेकसमशी पडताळणी करा. बॉडी वाचल्याने आधी अनुपस्थित हेडर दिसू लागत नाही.

संबंधित लेख