R-proxy-diagnose: libcurl-weergawe, TLS-agterkant en protokolle
Ondersoek die weergawe, TLS-implementering en protokol-eienskappe van R se gekoppelde libcurl afsonderlik van 'n eksterne curl-uitvoerbare lêer.
Die R wat in 'n Conda-omgewing geïnstalleer is, kan 'n ander libcurl-bou as die curl-uitvoerbare lêer in die terminaal gebruik. Vra die R-sessie wat misluk watter biblioteek dit werklik het:
info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')Die karakterwaarde gee die gekoppelde libcurl-weergawe weer. Die ssl_version-eienskap daarvan identifiseer die TLS-implementering, terwyl protocols die bestemmingsprotokolle lys wat daardie biblioteek ondersteun. Dit beskryf R se ingeboude libcurl-pad, nie 'n shell-opdrag met die naam curl nie.
Pas die verslag by die aflaaimetode aan
download.file met method='libcurl' gebruik hierdie biblioteek. method='curl' begin die eksterne uitvoerbare lêer. Die huidige outomatiese HTTP(S)-keuse gebruik libcurl, en 'n NULL-waarde vir die download.file.method-opsie kan daardie verstek laat geld.
Voer die ondersoek uit in die werklike omgewing wat deur die taak of IDE gekies is. 'n Ander R-installasie kan 'n ander weergawe of TLS-agterkant rapporteer selfs wanneer sy skripte identies lyk.
'n Gelyste https-protokol beteken HTTPS-bestemmings word ondersteun. Dit bewys nie dat 'n spesifieke proxy-luisteraar TLS aanvaar nie. 'n Gewone HTTP-proxy vir 'n HTTPS-aflaai het steeds 'n http://-proxy-URL.
Hou die biblioteekverslag saam met die gekose metode en verbindingsfout. 'n Sertifikaatfout, 'n onondersteunde proxy-skema en 'n geweierde luisteraar bly verskillende bevindings; 'n weergawenommer alleen is nie hul diagnose nie.