¿Son estándar las variables de entorno HTTP_PROXY, HTTPS_PROXY y NO_PROXY?

Parece que muchos programas están diseñados para leer estas variables de entorno para decidir qué proxy utilizar para conectarse a un recurso en Internet. Esos programas también pueden tener su propia configuración de proxy individual, pero si no están configurados, usarán con gusto estas variables de entorno ...

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Sólo quiero saber:

• ¿Son estándar estas variables de entorno?
• ¿Existe una especificación escrita (puede ser por los fabricantes del sistema operativo?) Que recomienda el uso de estas variables de entorno?

Esto es más una convención que un estándar. Es probable que sea compatible con una o más bibliotecas de controladores de protocolo que realmente hacen las conexiones. Java usa propiedades similares en sus bibliotecas de protocolos.

Comprender y usar convenciones comunes hace que el desarrollo sea mucho más simple. También ayuda a implementar el principio de menor sorpresa y hace que los programas sean más propensos a hacerlo just work.

Estoy de acuerdo con la declaración de BillThor de que esto es más una convención que un estándar.
No sé el origen de estas variables, pero en el caso de HTTP en * nix, muchas convenciones parecen originarse en el comportamiento de la biblioteca libcurl HTTP y el programa curl de línea de comandos.

En https://curl.haxx.se/docs/manual.html hay una descripción de las variables de entorno relacionadas con el uso del proxy HTTP que entiende libcurl / curl:

VARIABLES DE ENTORNO

Curl lee y comprende las siguientes variables de entorno:
http_proxy, HTTPS_PROXY, FTP_PROXY

Deben configurarse para servidores proxy específicos del protocolo. El proxy general debe establecerse con
ALL_PROXY

Se establece una lista de nombres de host separados por comas que no deberían pasar por ningún proxy (solo un asterisco, '*' coincide con todos los hosts)
NO_PROXY

Si el nombre de host coincide con una de estas cadenas, o si el host está dentro del dominio de una de estas cadenas, las transacciones con ese nodo no se representarán.

Tenga en cuenta que http_proxyse escribe en minúsculas como la única entre estas variables. Algunas bibliotecas / programas buscan nombres en minúsculas de estas variables, mientras que otros buscan nombres en mayúsculas. Para estar seguro, uno debe definir las versiones en minúsculas y mayúsculas de cada variable.

Otro problema es que la descripción citada de cómo se comparan los nombres de host NO_PROXYno es precisa y no responde las siguientes preguntas:

• ¿Deben los valores ser nombres de dominio totalmente calificados (FQDN) que terminen con un punto como foo.example.com.o no?
• ¿Debería foo.example.comcoincidir solo con este dominio o también debería coincidir con cualquier subdominio como bar.foo.example.com? Si este último, ¿también debería coincidir con algún subdominio en algún subdominio como bar.baz.foo.example.com?
• ¿Está .foo.example.compermitido (punto al principio) y, de ser así, ¿qué debería coincidir?
• ¿Se *permite el asterisco ( ) como parte del valor ( *.example.com, *example.com) y, de ser así, ¿cómo se trata?

La falta de especificación formal conduce a confusión y errores. Aquí hay que mencionar la biblioteca libproxy que tiene como objetivo proporcionar soporte correcto y consistente para la configuración del proxy. Desde la página de inicio del proyecto :

libproxy existe para responder la pregunta: dado un recurso de red, ¿cómo puedo acceder a él? Maneja todos los detalles, lo que le permite volver a la programación.

Otras lecturas:

• Problema que planteé contra curl: documente la sintaxis y la semántica de la variable de entorno NO_PROXY.
• La edición de Python - urllib: valores de las variables no_proxy con punto inicial no se maneja adecuadamente y relacionado SO pregunta - Python 2.7.13 no respeta NO_PROXY y hace urllib2.urlopen () error con “conexión de túnel falló: 403 Prohibido”