As variáveis de ambiente HTTP_PROXY, HTTPS_PROXY e NO_PROXY são padrão?

Question

Parece que muitos programas são projetados para ler essas variáveis de ambiente para decidir qual proxy percorrer para se conectar a um recurso na Internet. Esses programas também podem ter suas próprias configurações de proxy individuais, mas se eles não estiverem definidos, eles usarão com satisfação essas variáveis de ambiente ...

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Eu só quero saber:

• Essas variáveis de ambiente são padrão?
• Existe uma especificação escrita (pode ser dos fabricantes do SO?) que recomenda o uso dessas variáveis de ambiente?

Answer 1

Isso é mais uma convenção do que um padrão. É provável que seja suportado por uma ou mais bibliotecas manipuladoras de protocolo que realmente fazem as conexões. Java usa propriedades semelhantes em suas bibliotecas de protocolo.

Entender e usar convenções comuns torna o desenvolvimento muito mais simples. Também ajuda a implementar o princípio da menor surpresa e torna os programas mais propensos a just work .

    

Answer 2

Concordo com a afirmação do BillThor de que isso é mais uma convenção do que um padrão.
Eu não sei a origem dessas variáveis, mas no caso de HTTP no * nix muitas convenções parecem ter origem no comportamento da biblioteca HTTP libcurl Enrole o programa de linha de comando.

No link , há uma descrição das variáveis de ambiente relacionadas ao uso do proxy HTTP que o libcurl / curl entende:

ENVIRONMENT VARIABLES

Curl reads and understands the following environment variables:
http_proxy, HTTPS_PROXY, FTP_PROXY

They should be set for protocol-specific proxies. General proxy should be set with
ALL_PROXY

A comma-separated list of host names that shouldn't go through any proxy is set in (only an asterisk, '*' matches all hosts)
NO_PROXY

If the host name matches one of these strings, or the host is within the domain of one of these strings, transactions with that node will not be proxied.

Por favor note que http_proxy é escrito em minúsculas como o único entre estas variáveis. Algumas bibliotecas / programas procuram nomes em minúsculas dessas variáveis, enquanto outros procuram nomes em destaque. Para ser seguro deve-se definir as versões em minúsculas e maiúsculas de cada variável.

Outro problema é que a descrição citada de como os nomes de host são comparados com NO_PROXY não é precisa e não responde às seguintes perguntas:

• Os valores devem ser nomes de domínio totalmente qualificados (FQDN) terminando assim com um ponto como foo.example.com. ou não?
• O foo.example.com deve corresponder apenas a este domínio ou também deve corresponder a qualquer subdomínio como bar.foo.example.com ? Se o último, então, deve também corresponder a qualquer subdomínio em qualquer subdomínio como bar.baz.foo.example.com ?
• O .foo.example.com (ponto no início) é permitido e, em caso afirmativo, o que deve corresponder?
• O asterisco ( * ) é permitido como parte do valor ( *.example.com , *example.com ) e, em caso afirmativo, como ele é tratado?

A falta de especificação formal leva a confusão e bugs. Aqui é preciso mencionar a biblioteca libproxy que visa fornecer suporte correto e consistente para a configuração de proxy. Na página inicial do projeto :

libproxy exists to answer the question: Given a network resource, how do I reach it? It handles all the details, enabling you to get back to programming.

Leitura adicional:

• Problema levantado contra o curl - Por favor, documente a sintaxe e a semântica da variável de ambiente NO_PROXY.
• Problema do Python - urllib: valores de variáveis no_proxy com pontos principais não tratados adequadamente e questões relacionadas SO - O Python 2.7.13 não respeita NO_PROXY e faz com que o erro urllib2.urlopen () com" Conexão de túnel falhou: 403 Proibido "