getContentLengthLong() == -1 vol dir que no hi ha cap longitud de contingut coneguda a les metadades disponibles. Continua llegint el flux i mostra els bytes rebuts o un progrés indeterminat; no ho tractis com una resposta buida ni assignis un buffer de mida negativa.

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

La connexió ja està configurada i el cridador és propietari de output. Mantén els temps d'espera de connexió i lectura i qualsevol límit de mida de l'aplicació al voltant d'aquest bucle. Un error d'E/S és una baixada fallida, no una finalització correcta amb menys bytes.

Compara longituds a la mateixa capa. La codificació chunked d'HTTP/1.1 pot substituir Content-Length i la descodifica la implementació HTTP. Un proxy pot reenquadrar-la. La descompressió també pot fer que el recompte de bytes descodificats de l'aplicació difereixi d'un Content-Length codificat.

Si apareixen alhora Transfer-Encoding i Content-Length, no triïs un número convenient: l'enquadrament HTTP dóna precedència a la codificació de transferència i tracta la combinació com un possible error. Deixa aquesta anàlisi a una implementació conforme.

Una URL FTP a través d'una passarel·la HTTP necessita comprovar el comportament concret de URLConnection; no garanteix que cada accessor de capçalera HTTP es comporti com en una URL HTTP ordinària a cada JDK. Fes servir l'API de longitud amb valor llarg quan les metadades importen, i valida l'artefacte completat contra la longitud o la suma de verificació realment requerides. Llegir el cos no fa aparèixer una capçalera que abans era absent.

Articles relacionats