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 ஐப் பயன்படுத்துங்கள், முடிக்கப்பட்ட தயாரிப்பை உண்மையில் தேவைப்படும் நீளம் அல்லது செக்சம் உடன் சரிபார்க்கவும். உடலைப் படிப்பது முன்பு இல்லாத தலைப்பைத் தோற்றுவிக்காது.