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 ప్రవర్తనను తనిఖీ చేయాలి; ప్రతి JDK లో ప్రతి HTTP హెడర్ యాక్సెస్ సాధారణ HTTP URL లాగా ప్రవర్తిస్తుందని అది హామీ ఇవ్వదు. మెటాడేటా ముఖ్యమైన చోట దీర్ఘ విలువ గల length API ఉపయోగించండి, మరియు పూర్తయిన ఆర్టిఫ్యాక్ట్‌ను నిజంగా అవసరమైన పొడవు లేదా చెక్‌సమ్‌తో ధృవీకరించండి. బాడీ చదవడం ముందు లేని హెడర్ కనిపించేలా చేయదు.

సంబంధిత వ్యాసాలు