Diagnostika ng proxy sa R: bersyon ng libcurl, TLS backend at mga protocol
Suriin ang bersyon, implementasyon ng TLS at mga katangian ng protocol ng libcurl na naka-link sa R nang hiwalay sa isang panlabas na executable na curl.
Ang R na naka-install sa isang kapaligirang Conda ay maaaring gumamit ng ibang build ng libcurl kaysa sa executable na curl sa terminal. Tanungin ang R session na bumabagsak kung aling library ang mayroon talaga ito:
info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')Ang halaga ng karakter ay nag-uulat ng bersyon ng naka-link na libcurl. Tinutukoy ng attribute nitong ssl_version ang implementasyon ng TLS, samantalang inililista ng protocols ang mga destinasyong protocol na sinusuportahan ng library na iyon. Inilalarawan nila ang built-in na landas ng libcurl sa R, hindi isang shell command na pinangalanang curl.
Itugma ang ulat sa paraan ng pag-download
Ang download.file na may method='libcurl' ay gumagamit ng library na ito. Ang method='curl' ay naglulunsad ng panlabas na executable. Ang kasalukuyang awtomatikong pagpili ng HTTP(S) ay gumagamit ng libcurl, at ang opsyon na download.file.method na may halagang NULL ay maaaring iwanan ang default na iyon.
Patakbuhin ang inspeksyon sa aktwal na kapaligirang pinili ng trabaho o IDE. Ang ibang pag-install ng R ay maaaring mag-ulat ng ibang bersyon o TLS backend kahit na magkapareho ang hitsura ng mga script nito.
Ang nakalistang https protocol ay nangangahulugang sinusuportahan ang mga destinasyong HTTPS. Hindi nito pinapatunayan na tumatanggap ng TLS ang isang partikular na tagapakinig ng proxy. Ang ordinaryong HTTP proxy para sa download na HTTPS ay mayroon pa ring proxy URL na http://.
Itabi ang ulat ng library kasama ng napiling paraan at error sa koneksyon. Ang pagpalya ng sertipiko, hindi sinusuportahang scheme ng proxy at tinanggihang tagapakinig ay nananatiling magkakaibang natuklasan; ang numero ng bersyon lamang ay hindi ang diagnosis ng mga ito.