Diagnostic de proxy dans R : version de libcurl, backend TLS et protocoles
Inspectez la version, l'implémentation TLS et les attributs de protocole du libcurl lié à R séparément d'un exécutable curl externe.
Le R installé dans un environnement Conda peut utiliser une compilation de libcurl différente de l'exécutable curl du terminal. Demandez à la session R qui échoue quelle bibliothèque elle possède réellement :
info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')La valeur de caractères indique la version du libcurl lié. Son attribut ssl_version identifie l'implémentation TLS, tandis que protocols énumère les protocoles de destination pris en charge par cette bibliothèque. Ils décrivent le chemin libcurl intégré de R, et non une commande shell nommée curl.
Faites correspondre le rapport à la méthode de téléchargement
download.file avec method='libcurl' utilise cette bibliothèque. method='curl' lance l'exécutable externe. La sélection automatique actuelle de HTTP(S) utilise libcurl, et une option download.file.method à valeur NULL peut laisser cette valeur par défaut en place.
Exécutez l'inspection dans l'environnement réel choisi par la tâche ou l'IDE. Une autre installation de R peut signaler une autre version ou un autre backend TLS même lorsque ses scripts semblent identiques.
Un protocole https répertorié signifie que les destinations HTTPS sont prises en charge. Cela ne prouve pas qu'un écouteur de proxy particulier accepte TLS. Un proxy HTTP ordinaire pour un téléchargement HTTPS possède encore une URL de proxy en http://.
Conservez le rapport de la bibliothèque à côté de la méthode choisie et de l'erreur de connexion. Un échec de certificat, un schéma de proxy non pris en charge et un écouteur refusé restent des constats différents ; un simple numéro de version n'est pas leur diagnostic.