Czy zmienne środowiskowe HTTP_PROXY, HTTPS_PROXY i NO_PROXY są standardowe?

Wygląda na to, że wiele programów zaprojektowano tak, aby odczytywały te zmienne środowiskowe i decydowały, przez które proxy przejść, aby połączyć się z zasobem w Internecie. Programy te mogą mieć także własne, indywidualne ustawienia proxy, ale jeśli nie zostaną ustawione, chętnie wykorzystają te zmienne środowiskowe ...

• HTTP PROXY
• HTTPS_PROXY
• NO_PROXY

Chcę po prostu wiedzieć:

• Czy te zmienne środowiskowe są standardowe?
• Czy istnieje pisemna specyfikacja (może być przez producentów systemów operacyjnych?), Która zaleca stosowanie tych zmiennych środowiskowych?

Zgadzam się z oświadczeniem BillThor, że jest to bardziej konwencja niż norma.
Nie znam pochodzenia tych zmiennych, ale w przypadku HTTP na * nix wiele konwencji wydaje się wynikać z zachowania biblioteki HTTP libcurl i programu wiersza poleceń curl.

Na https://curl.haxx.se/docs/manual.html znajduje się opis zmiennych środowiskowych związanych z używaniem proxy HTTP, które libcurl / curl rozumie:

ZMIENNE ŚRODOWISKA

Curl czyta i rozumie następujące zmienne środowiskowe:
http_proxy, HTTPS_PROXY, FTP_PROXY

Powinny być ustawione dla serwerów proxy specyficznych dla protokołu. Ogólne proxy powinno być ustawione na
ALL_PROXY

Ustawiona jest rozdzielona przecinkami lista nazw hostów, które nie powinny przechodzić przez żaden serwer proxy (tylko gwiazdka, „*” pasuje do wszystkich hostów)
NO_PROXY

Jeśli nazwa hosta pasuje do jednego z tych ciągów lub host znajduje się w domenie jednego z tych ciągów, transakcje z tym węzłem nie będą proxy.

Zauważ, że http_proxypisownia jest pisana małymi literami jako jedyna spośród tych zmiennych. Niektóre biblioteki / programy szukają małych liter tych zmiennych, podczas gdy inne szukają wielkich liter. Aby być bezpiecznym, należy zdefiniować zarówno małe, jak i wielkie wersje każdej zmiennej.

Innym problemem jest to, że cytowany opis sposobu dopasowania nazw hostów NO_PROXYnie jest precyzyjny i nie odpowiada na następujące pytania:

• Czy wartości powinny być w pełni kwalifikowanymi nazwami domen (FQDN), które powinny kończyć się kropką jak foo.example.com.lub nie?
• Czy powinien foo.example.compasować tylko do tej jednej domeny, czy też powinien pasować do dowolnej subdomeny bar.foo.example.com? Jeśli ta ostatnia, to powinna również pasować do dowolnej subdomeny w dowolnej subdomenie, takiej jak bar.baz.foo.example.com?
• Czy .foo.example.com(kropka na początku) jest dozwolona, ​​a jeśli tak, to co powinna pasować?
• Czy gwiazdka ( *) jest dozwolona jako część wartości ( *.example.com, *example.com), a jeśli tak, to w jaki sposób jest traktowana?

Brak formalnej specyfikacji prowadzi do zamieszania i błędów. W tym miejscu należy wspomnieć o bibliotece libproxy, która ma na celu zapewnienie poprawnej i spójnej obsługi konfiguracji proxy. Ze strony głównej projektu :

libproxy istnieje, aby odpowiedzieć na pytanie: Jak uzyskać zasób sieciowy, jak mogę do niego dotrzeć? Obsługuje wszystkie szczegóły, umożliwiając powrót do programowania.

Dalsza lektura:

• Problem, który podniosłem przeciwko zwijaniu się - Proszę udokumentować składnię i semantykę zmiennej środowiskowej NO_PROXY.
• Problem Pythona - urllib: wartości zmiennych no_proxy z kropką wiodącą nieprawidłowo obsługiwaną i powiązane pytanie SO - Python 2.7.13 nie respektuje NO_PROXY i powoduje błąd urllib2.urlopen () z „Błąd połączenia tunelowego: 403 zabronione”

To bardziej konwencja niż standard. Prawdopodobnie jest obsługiwany przez jedną lub więcej bibliotek obsługi protokołu, które faktycznie wykonują połączenia. Java używa podobnych właściwości w bibliotekach protokołów.

Zrozumienie i stosowanie wspólnych konwencji znacznie upraszcza programowanie. Pomaga także wdrożyć zasadę najmniejszego zaskoczenia i zwiększyć prawdopodobieństwo wystąpienia programów just work.