Vipakuliwa vya Java kupitia proksi wakati getContentLengthLong inarudisha -1

getContentLengthLong() == -1 inamaanisha hakuna urefu wa maudhui unaojulikana katika metadata inayopatikana. Endelea kusoma mtiririko na uonyeshe baiti zilizopokelewa au maendeleo yasiyojulikana; usiichukue kama jibu tupu na usitenge akiba ya ukubwa hasi.

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;
    }
}

Muunganisho tayari umesanidiwa na output inamilikiwa na mpigaji simu. Weka muda wa mwisho wa muunganisho na usomaji pamoja na kikomo chochote cha ukubwa cha programu kuzunguka kitanzi hiki. Hitilafu ya I/O ni upakuaji ulioshindikana, si ukamilishaji uliofanikiwa kwa baiti chache.

Linganisha urefu katika tabaka moja. Usimbaji wa chunked wa HTTP/1.1 unaweza kuchukua nafasi ya Content-Length na husimbuliwa na utekelezaji wa HTTP. Proksi inaweza kuubadilisha muundo. Upunguzaji wa msongamano unaweza pia kufanya hesabu ya baiti zilizosimbuliwa za programu itofautiane na Content-Length iliyosimbwa.

Ikiwa Transfer-Encoding na Content-Length zote zinaonekana, usichague nambari inayofaa: uwekaji fremu wa HTTP unatoa kipaumbele kwa usimbaji wa uhamishaji na huchukua mchanganyiko huo kama hitilafu inayowezekana. Acha uchambuzi huo kwa utekelezaji unaofuata.

URL ya FTP kupitia lango la HTTP inahitaji kukaguliwa kwa tabia mahususi ya URLConnection; haitoi uhakika kwamba kila kifizishi cha kichwa cha HTTP kitafanya kama kwenye URL ya HTTP ya kawaida katika kila JDK. Tumia length API yenye thamani ndefu pale metadata inapojalisha, na thibitisha kipengele kilichokamilika dhidi ya urefu au checksum inayohitajika kwa kweli. Kusoma mwili hakufanyi kichwa kilichokosekana awali kionekane.