getContentLengthLong -1 ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ Java ਪ੍ਰੌਕਸੀ ਡਾਊਨਲੋਡ

getContentLengthLong() == -1 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਪਲਬਧ ਮੈਟਾਡੇਟਾ ਵਿੱਚ ਕੋਈ ਜਾਣੀ ਹੋਈ ਸਮੱਗਰੀ ਲੰਬਾਈ ਨਹੀਂ ਹੈ। ਸਟ੍ਰੀਮ ਪੜ੍ਹਨਾ ਜਾਰੀ ਰੱਖੋ ਅਤੇ ਪ੍ਰਾਪਤ ਬਾਈਟ ਜਾਂ ਅਨਿਸ਼ਚਿਤ ਤਰੱਕੀ ਦਿਖਾਓ; ਇਸਨੂੰ ਖਾਲੀ ਜਵਾਬ ਨਾ ਮੰਨੋ ਅਤੇ ਰਿਣਾਤਮਕ ਆਕਾਰ ਦਾ ਬਫਰ ਨਾ ਅਲਾਟ ਕਰੋ।

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

ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਕਨਫਿਗਰ ਹੈ ਅਤੇ output ਕਾਲਰ ਦੀ ਮਲਕੀਅਤ ਹੈ। ਇਸ ਲੂਪ ਦੁਆਲੇ ਕਨੈਕਸ਼ਨ ਅਤੇ ਪੜ੍ਹਨ ਦੇ ਟਾਈਮਆਊਟ ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕੋਈ ਵੀ ਸਾਈਜ਼ ਸੀਮਾ ਰੱਖੋ। I/O ਗਲਤੀ ਅਸਫਲ ਡਾਊਨਲੋਡ ਹੈ, ਘੱਟ ਬਾਈਟਾਂ ਨਾਲ ਸਫਲ ਮੁਕੰਮਲ ਹੋਣਾ ਨਹੀਂ।

ਲੰਬਾਈਆਂ ਦੀ ਤੁਲਨਾ ਇੱਕੋ ਪਰਤ 'ਤੇ ਕਰੋ। HTTP/1.1 ਦੀ chunked ਐਨਕੋਡਿੰਗ Content-Length ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ ਅਤੇ HTTP ਲਾਗੂਕਰਨ ਇਸਨੂੰ ਡੀਕੋਡ ਕਰਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਇਸਨੂੰ ਦੁਬਾਰਾ ਫਰੇਮ ਕਰ ਸਕਦੀ ਹੈ। ਡੀਕੰਪ੍ਰੈਸ਼ਨ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਡੀਕੋਡ ਕੀਤੀ ਬਾਈਟ ਗਿਣਤੀ ਨੂੰ ਐਨਕੋਡ ਕੀਤੇ Content-Length ਤੋਂ ਵੱਖਰਾ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇ Transfer-Encoding ਅਤੇ Content-Length ਦੋਵੇਂ ਦਿਸਦੇ ਹਨ, ਤਾਂ ਸੁਵਿਧਾਜਨਕ ਸੰਖਿਆ ਨਾ ਚੁਣੋ: HTTP ਫਰੇਮਿੰਗ ਟ੍ਰਾਂਸਫਰ ਐਨਕੋਡਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਅਤੇ ਸੰਜੋਗ ਨੂੰ ਸੰਭਾਵੀ ਗਲਤੀ ਮੰਨਦੀ ਹੈ। ਉਹ ਪਾਰਸਿੰਗ ਅਨੁਕੂਲ ਲਾਗੂਕਰਨ 'ਤੇ ਛੱਡੋ।

HTTP ਗੇਟਵੇ ਰਾਹੀਂ FTP URL ਲਈ ਇਸਦੇ ਠੋਸ URLConnection ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਲੋੜੀਂਦੀ ਹੈ; ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਕਿ ਹਰ JDK ਵਿੱਚ ਹਰ HTTP ਹੈਡਰ ਐਕਸੈਸਰ ਆਮ HTTP URL ਵਾਂਗ ਵਿਵਹਾਰ ਕਰੇਗਾ। ਜਿੱਥੇ ਮੈਟਾਡੇਟਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉੱਥੇ ਲੰਬੇ ਮੁੱਲ ਵਾਲੀ length API ਵਰਤੋ, ਅਤੇ ਮੁਕੰਮਲ ਆਰਟੀਫੈਕਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੀ ਲੰਬਾਈ ਜਾਂ ਚੈਕਸਮ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰੋ। ਬਾਡੀ ਪੜ੍ਹਨ ਨਾਲ ਪਹਿਲਾਂ ਗੈਰਹਾਜ਼ਰ ਹੈਡਰ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦਾ।