Descărcări Java prin proxy când getContentLengthLong returnează -1

getContentLengthLong() == -1 înseamnă că nu există o lungime cunoscută a conținutului în metadatele disponibile. Continuă să citești fluxul și afișează octeții primiți sau un progres nedeterminat; nu îl trata ca răspuns gol și nu aloca un buffer de dimensiune negativă.

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

Conexiunea este deja configurată, iar output aparține apelantului. Păstrează timeout-urile de conexiune și citire și orice limită de dimensiune a aplicației în jurul acestei bucle. O eroare de I/O este o descărcare eșuată, nu o finalizare reușită cu mai puțini octeți.

Compară lungimile la același nivel. Codificarea chunked din HTTP/1.1 poate înlocui Content-Length și este decodată de implementarea HTTP. Un proxy o poate reîncadra. Și decomprimarea poate face ca numărul de octeți decodați ai aplicației să difere de un Content-Length codificat.

Dacă apar atât Transfer-Encoding, cât și Content-Length, nu alege un număr convenabil: încadrarea HTTP acordă prioritate codificării de transfer și tratează combinația ca o posibilă eroare. Lasă acea analiză unei implementări conforme.

Un URL FTP printr-o poartă HTTP necesită verificarea comportamentului concret al URLConnection; nu garantează că fiecare accesor de antet HTTP se comportă ca pe un URL HTTP obișnuit în orice JDK. Folosește API-ul de lungime cu valoare lungă acolo unde metadatele contează și validează artefactul finalizat față de lungimea sau suma de control cerute efectiv. Citirea corpului nu face să apară un antet care lipsea anterior.