Les variables d'environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY sont-elles standard?

Il semble que de nombreux programmes sont conçus pour lire ces variables d'environnement afin de décider par quel proxy passer pour se connecter à une ressource sur Internet. Ces programmes peuvent également avoir leurs propres paramètres de proxy individuels, mais s'ils ne sont pas définis, ils utiliseront volontiers ces variables d'environnement ...

• HTTP PROXY
• HTTPS_PROXY
• NO_PROXY

Je veux juste savoir:

• Ces variables d'environnement sont-elles standard?
• Existe-t-il une spécification écrite (pouvant être fournie par les fabricants de systèmes d'exploitation?) Qui recommande l'utilisation de ces variables d'environnement?

Je suis d'accord avec la déclaration de BillThor selon laquelle il s'agit plus d'une convention que d'une norme.
Je ne connais pas l'origine de ces variables mais dans le cas de HTTP sur * nix, de nombreuses conventions semblent provenir du comportement de la bibliothèque HTTP libcurl et du programme de ligne de commande curl.

Sur https://curl.haxx.se/docs/manual.html, il y a une description des variables d'environnement liées à l'utilisation du proxy HTTP que libcurl / curl comprend:

VARIABLES D'ENVIRONNEMENT

Curl lit et comprend les variables d'environnement suivantes:
http_proxy, HTTPS_PROXY, FTP_PROXY

Ils doivent être définis pour les proxys spécifiques au protocole. Le proxy général doit être défini avec
ALL_PROXY

Une liste de noms d'hôtes séparés par des virgules qui ne doivent passer par aucun proxy est définie (seul un astérisque, '*' correspond à tous les hôtes)
NO_PROXY

Si le nom d'hôte correspond à l'une de ces chaînes ou si l'hôte se trouve dans le domaine de l'une de ces chaînes, les transactions avec ce nœud ne seront pas mandatées.

Veuillez noter qu'il http_proxyest orthographié en minuscules comme la seule parmi ces variables. Certaines bibliothèques / programmes recherchent des noms en minuscules de ces variables tandis que d'autres recherchent des noms en majuscules. Pour être sûr, il faut définir les versions en minuscules et en majuscules de chaque variable.

Un autre problème est que la description citée de la façon dont les noms d'hôte sont comparés NO_PROXYn'est pas précise et ne répond pas aux questions suivantes:

• Les valeurs doivent-elles être des noms de domaine pleinement qualifiés (FQDN) se terminant ainsi par un point semblable foo.example.com.ou non?
• Doit foo.example.comcorrespondre uniquement à ce domaine ou doit-il également correspondre à un sous-domaine similaire bar.foo.example.com? Si ce dernier doit alors correspondre à n'importe quel sous-domaine dans n'importe quel sous-domaine comme bar.baz.foo.example.com?
• Le .foo.example.com(point au début) est-il autorisé et si oui, à quoi devrait-il correspondre?
• L'astérisque ( *) est-il autorisé dans le cadre de la valeur ( *.example.com, *example.com) et si oui, comment est-il traité?

Le manque de spécification formelle conduit à la confusion et aux bugs. Ici, il faut mentionner la bibliothèque libproxy qui vise à fournir un support correct et cohérent pour la configuration du proxy. Depuis la page d' accueil du projet :

libproxy existe pour répondre à la question: Étant donné une ressource réseau, comment puis-je l'atteindre? Il gère tous les détails, vous permettant de revenir à la programmation.

Lectures complémentaires:

• Problème que j'ai soulevé contre curl - Veuillez documenter la syntaxe et la sémantique de la variable d'environnement NO_PROXY.
• Problème de Python - urllib: valeurs de variable no_proxy avec le point principal non correctement géré et question SO connexe - Python 2.7.13 ne respecte pas NO_PROXY et fait une erreur urllib2.urlopen () avec "Échec de la connexion du tunnel: 403 interdit"

C'est plus une convention qu'une norme. Il est probablement pris en charge par une ou plusieurs bibliothèques de gestionnaires de protocoles qui établissent réellement les connexions. Java utilise des propriétés similaires dans ses bibliothèques de protocoles.

Comprendre et utiliser des conventions communes rend le développement beaucoup plus simple. Il aide également à mettre en œuvre le principe de la moindre surprise et à rendre les programmes plus susceptibles de le faire just work.