Java-Downloads über Proxy, wenn getContentLengthLong -1 zurückgibt

getContentLengthLong() == -1 bedeutet, dass in den verfügbaren Metadaten keine bekannte Inhaltslänge vorliegt. Lies den Stream weiter und zeige empfangene Bytes oder unbestimmten Fortschritt; behandle das nicht als leere Antwort und reserviere keinen Puffer mit negativer Größe.

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

Die Verbindung ist bereits konfiguriert, und output gehört dem Aufrufer. Behalte Verbindungs- und Lese-Timeouts sowie jede Größenbeschränkung der Anwendung um diese Schleife bei. Ein E/A-Fehler ist ein fehlgeschlagener Download, kein erfolgreicher Abschluss mit weniger Bytes.

Vergleiche Längen auf derselben Ebene. Chunked-Kodierung in HTTP/1.1 kann Content-Length ersetzen und wird von der HTTP-Implementierung dekodiert. Ein Proxy kann sie neu rahmen. Auch Dekompression kann dazu führen, dass die dekodierte Bytezahl der Anwendung von einer kodierten Content-Length abweicht.

Treten Transfer-Encoding und Content-Length gemeinsam auf, wähle keine bequeme Zahl: Das HTTP-Framing gibt der Transferkodierung Vorrang und behandelt die Kombination als möglichen Fehler. Überlasse diese Auswertung einer konformen Implementierung.

Eine FTP-URL über ein HTTP-Gateway erfordert die Prüfung des konkreten URLConnection-Verhaltens; es garantiert nicht, dass sich jeder HTTP-Header-Zugriff in jedem JDK wie bei einer gewöhnlichen HTTP-URL verhält. Verwende die Length-API mit long-Wert, wo Metadaten zählen, und validiere das fertige Artefakt gegen die tatsächlich erforderliche Länge oder Prüfsumme. Das Lesen des Bodys lässt einen zuvor fehlenden Header nicht erscheinen.