Java-proxy-aflaaie wanneer getContentLengthLong -1 teruggee

getContentLengthLong() == -1 beteken dat daar geen bekende inhoudslengte in die beskikbare metadata is nie. Hou aan om die stroom te lees en wys ontvangde grepe of onbepaalde vordering; moenie dit as 'n leë antwoord behandel of 'n buffer met negatiewe grootte toeken nie.

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 verbinding is reeds opgestel en die oproeper besit output. Hou verbinding- en lees-tydsverloppe en enige groottebeperking van die toepassing rondom hierdie lus. 'n I/O-fout is 'n mislukte aflaai, nie suksesvolle voltooiing met minder grepe nie.

Vergelyk lengtes op dieselfde vlak. HTTP/1.1 se chunked-kodering kan Content-Length vervang en word deur die HTTP-implementering gedekodeer. 'n Proxy kan dit herverpak. Dekompressie kan ook veroorsaak dat die toepassing se gedekodeerde grepe-telling van 'n gekodeerde Content-Length verskil.

As beide Transfer-Encoding en Content-Length verskyn, moenie 'n gerieflike getal kies nie: HTTP-raamwerk gee aan die oordragkodering voorrang en behandel die kombinasie as 'n moontlike fout. Laat daardie ontleding aan 'n konformerende implementering oor.

'n FTP-URL deur 'n HTTP-gateway vereis dat sy konkrete URLConnection-gedrag nagegaan word; dit waarborg nie dat elke HTTP-kop-toegangspunt soos by 'n gewone HTTP-URL in elke JDK werk nie. Gebruik die lang-waarde-lengte-API waar metadata saak maak, en valideer die voltooide artefak teen die lengte of kontrolesom wat werklik vereis word. Om die liggaam te lees, laat nie 'n voorheen afwesige kop verskyn nie.