Le variabili d'ambiente HTTP_PROXY, HTTPS_PROXY e NO_PROXY sono standard?

Sembra che molti programmi siano progettati per leggere queste variabili d'ambiente per decidere quale proxy passare attraverso per connettersi a una risorsa su Internet. Questi programmi possono anche avere le proprie impostazioni proxy individuali, ma se non sono impostati, useranno felicemente queste variabili di ambiente ...

• HTTP_PROXY
• https_proxy
• NO_PROXY

Voglio solo sapere:

• Queste variabili d'ambiente sono standard?
• Esiste una specifica scritta (potrebbe essere dei produttori del sistema operativo?) Che raccomanda l'uso di queste variabili d'ambiente?

Concordo con l'affermazione di BillThor secondo cui questa è più una convenzione che uno standard.
Non conosco l'origine di queste variabili, ma in caso di HTTP su * nix molte convenzioni sembrano provenire dal comportamento della libreria HTTP libcurl e dal programma della riga di comando curl.

A https://curl.haxx.se/docs/manual.html c'è una descrizione delle variabili d'ambiente relative all'uso del proxy HTTP che libcurl / curl comprende:

VARIABILI AMBIENTALI

Curl legge e comprende le seguenti variabili d'ambiente:
http_proxy, HTTPS_PROXY, FTP_PROXY

Dovrebbero essere impostati per proxy specifici del protocollo. Il proxy generale dovrebbe essere impostato con
ALL_PROXY

Viene impostato un elenco separato da virgole di nomi host che non devono passare attraverso alcun proxy (solo un asterisco, '*' corrisponde a tutti gli host)
NO_PROXY

Se il nome host corrisponde a una di queste stringhe o se l'host si trova nel dominio di una di queste stringhe, le transazioni con quel nodo non verranno sottoposte a proxy.

Si noti che http_proxyè scritto in minuscolo come l'unico tra queste variabili. Alcune librerie / programmi cercano nomi minuscoli di queste variabili, mentre altri cercano nomi maiuscoli. Per sicurezza si dovrebbero definire sia le versioni minuscole che maiuscole di ciascuna variabile.

Un altro problema è che la descrizione citata della corrispondenza dei nomi host NO_PROXYnon è precisa e non risponde alle seguenti domande:

• I valori devono essere nomi di dominio completi (FQDN) che terminano quindi con un punto simile foo.example.com.o no?
• Dovrebbe foo.example.comcorrispondere solo a questo dominio o dovrebbe corrispondere anche a un sottodominio simile bar.foo.example.com? Se quest'ultimo quindi dovrebbe corrispondere anche a qualsiasi sottodominio in un sottodominio simile bar.baz.foo.example.com?
• È .foo.example.com(dot all'inizio) ha permesso, e se è così allora che cosa dovrebbe corrispondere?
• L'asterisco ( *) è ammesso come parte del valore ( *.example.com, *example.com) e, in tal caso, come viene trattato?

La mancanza di specifiche formali porta a confusione e bug. Qui si deve menzionare la libreria libproxy che mira a fornire supporto corretto e coerente per la configurazione del proxy. Dalla home page del progetto :

libproxy esiste per rispondere alla domanda: data una risorsa di rete, come posso raggiungerla? Gestisce tutti i dettagli, consentendoti di tornare alla programmazione.

Ulteriori letture:

• Problema che ho sollevato contro l'arricciatura: documentare la sintassi e la semantica della variabile d'ambiente NO_PROXY.
• Problema di Python - urllib: valori variabili no_proxy con punto iniziale non gestito correttamente e relativa domanda SO - Python 2.7.13 non rispetta NO_PROXY e commette l'errore urllib2.urlopen () con "Connessione tunnel fallita: 403 proibito"

Questa è più una convenzione che uno standard. È probabilmente supportato da una o più librerie di gestori di protocollo che realizzano effettivamente le connessioni. Java utilizza proprietà simili nelle sue librerie di protocollo.

Comprendere e utilizzare convenzioni comuni rende lo sviluppo molto più semplice. Inoltre aiuta ad attuare il principio della minima sorpresa e a rendere i programmi più propensi a farlo just work.