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 സ്വഭാവം പരിശോധിക്കേണ്ടതുണ്ട്; ഓരോ HTTP ഹെഡർ ആക്സസറും ഓരോ JDK-യിലും സാധാരണ HTTP URL പോലെ പ്രവർത്തിക്കുമെന്ന് അത് ഉറപ്പുനൽകുന്നില്ല. മെറ്റാഡാറ്റ പ്രധാനമായിടത്ത് ദീർഘ മൂല്യമുള്ള length API ഉപയോഗിക്കുക, പൂർത്തിയായ ആർട്ടിഫാക്ട് യഥാർത്ഥത്തിൽ ആവശ്യമായ നീളമോ ചെക്ക്സമ്മോ ഉപയോഗിച്ച് സാധൂകരിക്കുക. ബോഡി വായിക്കുന്നത് മുമ്പ് ഇല്ലാതിരുന്ന ഹെഡർ പ്രത്യക്ഷമാക്കുന്നില്ല.