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 ବ୍ୟବହାର କରନ୍ତୁ, ଏବଂ ସମ୍ପୂର୍ଣ୍ଣ ହୋଇଥିବା ଆର୍ଟିଫ୍ୟାକ୍ଟକୁ ପ୍ରକୃତରେ ଆବଶ୍ୟକ ଲମ୍ବ କିମ୍ବା ଚେକସମ ସହିତ ଯାଞ୍ଚ କରନ୍ତୁ। ବଡି ପଢ଼ିଲେ ପୂର୍ବରୁ ଅନୁପସ୍ଥିତ ହେଡର ଦେଖାଯାଏ ନାହିଁ।