Java lejupielādes caur starpniekserveri, kad getContentLengthLong atgriež -1

Apstrādājiet nezināmu Content-Length Java lejupielādē caur starpniekserveri, neuzskatot trūkstošos izmēra metadatus par tukšu atbildi.

getContentLengthLong() == -1 nozīmē, ka pieejamajos metadatos nav zināma satura garuma. Turpiniet lasīt plūsmu un rādiet saņemtos baitus vai nenoteiktu progresu; neuzskatiet to par tukšu atbildi un nepiešķiriet negatīva izmēra buferi.

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

Savienojums jau ir konfigurēts, un output pieder izsaucējam. Saglabājiet savienojuma un lasīšanas taimautus un jebkuru lietojumprogrammas izmēra ierobežojumu ap šo cilpu. I/O kļūda ir neveiksmīga lejupielāde, nevis veiksmīga pabeigšana ar mazāk baitiem.

Salīdziniet garumus vienā slānī. HTTP/1.1 chunked kodējums var aizstāt Content-Length, un to atšifrē HTTP ieviešana. Starpniekserveris to var pārveidot rāmjos. Arī atspiešana var padarīt lietotnes atšifrēto baitu skaitu atšķirīgu no kodētā Content-Length.

Ja parādās gan Transfer-Encoding, gan Content-Length, neizvēlieties ērtu skaitli: HTTP ietvars dod priekšroku pārsūtīšanas kodējumam un uzskata kombināciju par iespējamu kļūdu. Atstājiet šo analīzi atbilstošai ieviešanai.

FTP URL caur HTTP vārteju prasa pārbaudīt konkrēto URLConnection uzvedību; tā negarantē, ka katra HTTP galvenes piekļuve uzvedas kā parastā HTTP URL jebkurā JDK. Izmantojiet garas vērtības length API tur, kur metadati ir svarīgi, un validējiet pabeigto artefaktu pret faktiski nepieciešamo garumu vai kontrolsummu. Pamatteksta lasīšana nepadara iepriekš trūkstošu galveni redzamu.

Saistītie raksti