Java preuzimanja preko proxyja kada getContentLengthLong vrati -1
Rukujte nepoznatim Content-Length u Java preuzimanju preko proxyja bez tretiranja nedostajućih metapodataka o veličini kao praznog odgovora.
getContentLengthLong() == -1 znači da u dostupnim metapodacima nema poznate duljine sadržaja. Nastavite čitati tok i prikazujte primljene bajtove ili neodređeni napredak; ne tretirajte to kao prazan odgovor i ne dodjeljujte međuspremnik negativne veličine.
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;
}
}
Veza je već konfigurirana, a output posjeduje pozivatelj. Zadržite vremenska ograničenja veze i čitanja te bilo koje ograničenje veličine aplikacije oko ove petlje. I/O pogreška je neuspjelo preuzimanje, a ne uspješan završetak s manje bajtova.
Uspoređujte duljine na istom sloju. HTTP/1.1 chunked kodiranje može zamijeniti Content-Length i dekodira ga HTTP implementacija. Proxy ga može ponovno uokviriti. Dekompresija također može učiniti da se dekodirani broj bajtova aplikacije razlikuje od kodiranog Content-Length.
Ako se pojave i Transfer-Encoding i Content-Length, nemojte birati prikladan broj: HTTP uokvirivanje daje prednost prijenosnom kodiranju i tretira kombinaciju kao moguću pogrešku. Prepustite to parsiranje usklađenoj implementaciji.
FTP URL kroz HTTP pristupnik zahtijeva provjeru konkretnog ponašanja URLConnection; ne jamči da se svaki pristup HTTP zaglavlju ponaša kao na običnom HTTP URL-u u svakom JDK-u. Koristite length API s dugom vrijednošću gdje su metapodaci važni i validirajte dovršeni artefakt prema stvarno potrebnoj duljini ili kontrolnom zbroju. Čitanje tijela ne čini ranije odsutno zaglavlje vidljivim.