Являются ли переменные среды HTTP_PROXY, HTTPS_PROXY и NO_PROXY стандартными?

Похоже, что многие программы предназначены для чтения этих переменных среды, чтобы решить, через какой прокси-сервер пройти, чтобы подключиться к ресурсу в Интернете. Эти программы могут также иметь свои собственные индивидуальные настройки прокси, но если они не установлены, они с радостью будут использовать эти переменные среды ...

• HTTP_PROXY
• https_proxy
• no_proxy

Я просто хочу знать:

• Являются ли эти переменные среды стандартными?
• Существует ли письменная спецификация (может быть от производителей ОС?), Которая рекомендует использовать эти переменные среды?

Я согласен с утверждением BillThor, что это скорее соглашение, чем стандарт.
Я не знаю происхождение этих переменных, но в случае HTTP на * nix многие соглашения возникают из-за поведения библиотеки libcurl HTTP и программы командной строки curl.

На https://curl.haxx.se/docs/manual.html есть описание переменных среды, связанных с использованием HTTP-прокси, которые понимает libcurl / curl:

ПЕРЕМЕННЫЕ ОКРУЖАЮЩЕЙ СРЕДЫ

Curl читает и понимает следующие переменные окружения:
http_proxy, HTTPS_PROXY, FTP_PROXY

Они должны быть установлены для протоколов для конкретного протокола. Общий прокси должен быть установлен с
ALL_PROXY

Задан разделенный запятыми список имен хостов, которые не должны проходить через прокси (только звездочка, '*' соответствует всем хостам)
NO_PROXY

Если имя хоста соответствует одной из этих строк или хост находится в домене одной из этих строк, транзакции с этим узлом не будут проксироваться.

Обратите внимание, что http_proxyпишется строчными буквами как единственная из этих переменных. Некоторые библиотеки / программы ищут имена этих переменных в нижнем регистре, тогда как другие ищут имена в верхнем регистре. Чтобы быть в безопасности, следует определять как строчные, так и прописные версии каждой переменной.

Другая проблема заключается в том, что приведенное описание сопоставления имен хостов не NO_PROXYявляется точным и не отвечает на следующие вопросы:

• Должны ли значения быть полностью определенными доменными именами (FQDN) и заканчиваться точкой как foo.example.com.или нет?
• Должен foo.example.comсовпадать только с этим одним доменом или с любым подобным поддоменом bar.foo.example.com? Если последнее, то оно также должно соответствовать любому субдомену в любом подобласти bar.baz.foo.example.com?
• .foo.example.comРазрешено ли (точка в начале) и если да, то что должно совпадать?
• *Допускается ли звездочка ( ) как часть значения ( *.example.com, *example.com), и если да, то как это обрабатывается?

Отсутствие формальной спецификации приводит к путанице и ошибкам. Здесь следует упомянуть библиотеку libproxy, которая призвана обеспечить правильную и согласованную поддержку конфигурации прокси. С домашней страницы проекта :

libproxy существует, чтобы ответить на вопрос: учитывая сетевой ресурс, как мне его достичь? Он обрабатывает все детали, позволяя вам вернуться к программированию.

Дальнейшее чтение:

• Проблема, которую я поднял против curl. Пожалуйста, документируйте синтаксис и семантику переменной среды NO_PROXY.
• Проблема Python - urllib: значения переменных no_proxy с начальной точкой неправильно обработаны и связанный с этим вопрос SO - Python 2.7.13 не учитывает NO_PROXY и выдает ошибку urllib2.urlopen () с сообщением «Ошибка подключения к туннелю: 403 запрещено»

Это скорее соглашение, чем стандарт. Скорее всего, это поддерживается одной или несколькими библиотеками обработчиков протоколов, которые фактически устанавливают соединения. Java использует аналогичные свойства в своих библиотеках протоколов.

Понимание и использование общих соглашений делает разработку намного проще. Это также помогает реализовать принцип наименьшего удивления и повышает вероятность программ just work.