Conda പരിതസ്ഥിതിയിൽ ഇൻസ്റ്റാൾ ചെയ്ത R ടെർമിനലിലെ curl എക്സിക്യൂട്ടബിളിൽ നിന്ന് വ്യത്യസ്തമായ libcurl ബിൽഡ് ഉപയോഗിച്ചേക്കാം. പരാജയപ്പെടുന്ന R സെഷനോട് അതിന് യഥാർത്ഥത്തിൽ ഏത് ലൈബ്രറിയാണുള്ളതെന്ന് ചോദിക്കുക:

info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')

അക്ഷര മൂല്യം ലിങ്ക് ചെയ്ത libcurl-ന്റെ പതിപ്പ് റിപ്പോർട്ട് ചെയ്യുന്നു. അതിന്റെ ssl_version ഗുണവിശേഷത TLS നടപ്പാക്കലിനെ തിരിച്ചറിയുന്നു, protocols ആ ലൈബ്രറി പിന്തുണയ്ക്കുന്ന ലക്ഷ്യ പ്രോട്ടോക്കോളുകൾ ലിസ്റ്റ് ചെയ്യുന്നു. ഇവ R-ന്റെ ഉൾനിർമ്മിത libcurl പാത വിവരിക്കുന്നു, curl എന്ന പേരിലുള്ള shell കമാൻഡ് അല്ല.

റിപ്പോർട്ട് ഡൗൺലോഡ് രീതിയുമായി ഒത്തുനോക്കുക

method='libcurl' ഉള്ള download.file ഈ ലൈബ്രറി ഉപയോഗിക്കുന്നു. method='curl' ബാഹ്യ എക്സിക്യൂട്ടബിൾ വിക്ഷേപിക്കുന്നു. നിലവിലെ സ്വയമേവയുള്ള HTTP(S) തിരഞ്ഞെടുപ്പ് libcurl ഉപയോഗിക്കുന്നു, NULL മൂല്യമുള്ള download.file.method ഓപ്ഷൻ ആ ഡിഫോൾട്ട് നിലനിർത്തിയേക്കാം.

ജോലിയോ IDE-യോ തിരഞ്ഞെടുക്കുന്ന യഥാർത്ഥ പരിതസ്ഥിതിയിൽ പരിശോധന നടത്തുക. മറ്റൊരു R ഇൻസ്റ്റലേഷൻ അതിന്റെ സ്ക്രിപ്റ്റുകൾ ഒരുപോലെ തോന്നിയാലും വ്യത്യസ്ത പതിപ്പോ TLS ബാക്കെൻഡോ റിപ്പോർട്ട് ചെയ്തേക്കാം.

പട്ടികയിൽ https പ്രോട്ടോക്കോൾ ഉണ്ടെന്നാൽ HTTPS ലക്ഷ്യങ്ങൾ പിന്തുണയ്ക്കുന്നു എന്നാണ്. അത് ഒരു നിർദ്ദിഷ്ട പ്രോക്സി ശ്രോതാവ് TLS സ്വീകരിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല. HTTPS ഡൗൺലോഡിനുള്ള സാധാരണ HTTP പ്രോക്സിക്കും ഇപ്പോഴും http:// പ്രോക്സി URL ഉണ്ട്.

ലൈബ്രറി റിപ്പോർട്ട് തിരഞ്ഞെടുത്ത രീതിയും കണക്ഷൻ പിശകും സഹിതം സൂക്ഷിക്കുക. സർട്ടിഫിക്കറ്റ് പരാജയം, പിന്തുണയില്ലാത്ത പ്രോക്സി സ്കീം, നിരസിക്കപ്പെട്ട ശ്രോതാവ് എന്നിവ വ്യത്യസ്ത കണ്ടെത്തലുകളായി തുടരുന്നു; പതിപ്പ് നമ്പർ മാത്രം അവയുടെ ഡയഗ്നോസിസ് അല്ല.

അനുബന്ധ ലേഖനങ്ങൾ