Java-nedladdningar via proxy när getContentLengthLong returnerar -1

getContentLengthLong() == -1 betyder att det inte finns någon känd innehållslängd i tillgängliga metadata. Fortsätt läsa strömmen och visa mottagna byte eller obestämt förlopp; behandla det inte som ett tomt svar och tilldela ingen buffert med negativ storlek.

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

Anslutningen är redan konfigurerad och output ägs av anroparen. Behåll tidsgränser för anslutning och läsning samt eventuell storleksgräns i programmet runt denna loop. Ett I/O-fel är en misslyckad nedladdning, inte ett lyckat slutförande med färre byte.

Jämför längder på samma lager. HTTP/1.1 chunked-kodning kan ersätta Content-Length och avkodas av HTTP-implementeringen. En proxy kan rama in den på nytt. Dekomprimering kan också göra att programmets avkodade byteantal skiljer sig från en kodad Content-Length.

Om både Transfer-Encoding och Content-Length förekommer ska du inte välja ett bekvämt tal: HTTP-ramning ger överföringskodning företräde och behandlar kombinationen som ett möjligt fel. Lämna den tolkningen till en kompatibel implementering.

En FTP-URL via en HTTP-gateway kräver kontroll av det konkreta URLConnection-beteendet; det garanterar inte att varje HTTP-header-åtkomst beter sig som på en vanlig HTTP-URL i varje JDK. Använd length-API:t med långt värde där metadata spelar roll, och validera den färdiga artefakten mot den längd eller kontrollsumma som faktiskt krävs. Att läsa brödtexten får inte en tidigare saknad header att dyka upp.