Conda გარემოში დაინსტალირებულ R-ს შეიძლება ჰქონდეს ტერმინალში არსებული curl-ის შესრულებადი ფაილისგან განსხვავებული libcurl-ის აწყობა. ჰკითხეთ წარუმატებელ R სესიას, რომელი ბიბლიოთეკა აქვს რეალურად:

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

სიმბოლოთა მნიშვნელობა გვატყობინებს მიბმული libcurl-ის ვერსიას. მისი ssl_version ატრიბუტი განსაზღვრავს TLS იმპლემენტაციას, ხოლო protocols ჩამოთვლის ამ ბიბლიოთეკის მიერ მხარდაჭერილ სამიზნე პროტოკოლებს. ისინი აღწერენ R-ის ჩაშენებულ libcurl-ის გზას და არა curl სახელის მქონე shell ბრძანებას.

შეადარეთ ანგარიში ჩამოტვირთვის მეთოდს

download.file method='libcurl'-ით იყენებს ამ ბიბლიოთეკას. method='curl' უშვებს გარე შესრულებად ფაილს. HTTP(S)-ის მიმდინარე ავტომატური არჩევანი იყენებს libcurl-ს, და download.file.method პარამეტრს NULL მნიშვნელობით შეუძლია ეს ნაგულისხმევი დატოვოს ძალაში.

შემოწმება ჩაატარეთ იმ რეალურ გარემოში, რომელსაც სამუშაო ან IDE ირჩევს. R-ის სხვა ინსტალაციამ შეიძლება სხვა ვერსია ან TLS backend მოგვახსენოს მაშინაც, როცა მისი სკრიპტები იდენტურად გამოიყურება.

სიაში https პროტოკოლის არსებობა ნიშნავს, რომ HTTPS სამიზნეები მხარდაჭერილია. ეს არ ამტკიცებს, რომ კონკრეტული პროქსის მსმენელი იღებს TLS-ს. HTTPS ჩამოტვირთვისთვის ჩვეულებრივ HTTP პროქსის კვლავ აქვს http:// პროქსის URL.

შეინახეთ ბიბლიოთეკის ანგარიში არჩეულ მეთოდთან და კავშირის შეცდომასთან ერთად. სერტიფიკატის მარცხი, მხარდაუჭერელი პროქსის სქემა და უარყოფილი მსმენელი რჩება სხვადასხვა აღმოჩენად; მხოლოდ ვერსიის ნომერი მათი დიაგნოზი არ არის.

დაკავშირებული სტატიები