A getContentLengthLong() == -1 azt jelenti, hogy a rendelkezésre álló metaadatokban nincs ismert tartalomhossz. Folytassa a stream olvasását, és jelenítse meg a fogadott bájtokat vagy a határozatlan előrehaladást; ne tekintse üres válasznak, és ne foglaljon negatív méretű puffert.

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

A kapcsolat már be van állítva, és a output a hívó tulajdona. Tartsa meg a kapcsolódási és olvasási időtúllépéseket, valamint az alkalmazás bármilyen méretkorlátját e ciklus körül. Az I/O hiba sikertelen letöltés, nem sikeres befejezés kevesebb bájttal.

Ugyanazon a rétegen hasonlítsa össze a hosszakat. A HTTP/1.1 chunked kódolása helyettesítheti a Content-Length-et, és a HTTP-implementáció dekódolja. Egy proxy újrakeretezheti. A tömörítés feloldása is eltérítheti az alkalmazás dekódolt bájtszámát a kódolt Content-Length-től.

Ha a Transfer-Encoding és a Content-Length is megjelenik, ne válasszon kényelmes számot: a HTTP-keretezés elsőbbséget ad az átviteli kódolásnak, és a kombinációt lehetséges hibának tekinti. Hagyja ezt az elemzést egy megfelelő implementációra.

A HTTP-átjárón keresztüli FTP URL esetében ellenőrizni kell a konkrét URLConnection-viselkedést; nem garantálja, hogy minden HTTP-fejléc-hozzáférés úgy viselkedik, mint egy közönséges HTTP URL esetén minden JDK-ban. Használja a hosszú értékű length API-t ott, ahol a metaadat számít, és érvényesítse a kész artefaktot a ténylegesen szükséges hossz vagy ellenőrzőösszeg ellenében. A törzs olvasása nem teszi megjelenővé a korábban hiányzó fejlécet.

Kapcsolódó cikkek