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 વાપરો, અને પૂર્ણ થયેલા આર્ટિફેક્ટને ખરેખર જરૂરી લંબાઈ અથવા ચેકસમ સામે માન્ય કરો. બોડી વાંચવાથી પહેલા ગેરહાજર હેડર દેખાતું નથી.