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 থাকে।

লাইব্রেরি রিপোর্টটি নির্বাচিত পদ্ধতি ও সংযোগ ত্রুটির সাথে রাখুন। সার্টিফিকেট ব্যর্থতা, অসমর্থিত প্রক্সি স্কিম ও প্রত্যাখ্যাত লিসেনার আলাদা আলাদা ফলাফলই থাকে; কেবল সংস্করণ নম্বর তাদের রোগনির্ণয় নয়।

সম্পর্কিত নিবন্ধ