د Java پروکسي ډاونلوډونه کله چې getContentLengthLong -1 بیرته راولي

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 وکاروئ، او بشپړ شوی آرټیفکټ د واقعي اړین اوږدوالي یا checksum سره تایید کړئ. د بدن لوستل دمخه نیمګړی سرلیک ښکاره نه کوي.