Java-letöltések proxy-n keresztül, amikor a getContentLengthLong -1-et ad vissza
Kezelje az ismeretlen Content-Length-et proxyn át történő Java-letöltésnél anélkül, hogy a hiányzó méret-metaadatot üres válasznak tekintené.
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.