getContentLengthLong -1 ಹಿಂತಿರುಗಿಸಿದಾಗ Java ಪ್ರಾಕ್ಸಿ ಡೌನ್‌ಲೋಡ್‌ಗಳು

ಪ್ರಾಕ್ಸಿ ಮೂಲಕ Java ಡೌನ್‌ಲೋಡ್‌ನಲ್ಲಿ ಅಪರಿಚಿತ Content-Length ಅನ್ನು ನಿರ್ವಹಿಸಿ, ಕಾಣೆಯಾದ ಗಾತ್ರ ಮೆಟಾಡೇಟಾವನ್ನು ಖಾಲಿ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದು ಪರಿಗಣಿಸದೆ.

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 ಬಳಸಿ, ಮತ್ತು ಪೂರ್ಣಗೊಂಡ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ಅಗತ್ಯವಿರುವ ಉದ್ದ ಅಥವಾ ಚೆಕ್‌ಸಮ್ ವಿರುದ್ಧ ಮಾನ್ಯಗೊಳಿಸಿ. ಬಾಡಿ ಓದುವುದರಿಂದ ಹಿಂದೆ ಇಲ್ಲದ ಹೆಡರ್ ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು