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

24

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

  • HTTP_PROXY
  • https_proxy
  • no_proxy

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

  • Являются ли эти переменные среды стандартными?
  • Существует ли письменная спецификация (может быть от производителей ОС?), Которая рекомендует использовать эти переменные среды?
Нико Беллик
источник
1
Я не знаю no_proxy, но http_proxy (написано строчными буквами) является стандартным
Uwe Burger
@UweBurger, возможно, вы можете указать, какие программы его используют .. И это касается и спрашивающего. Я видел это на wget
barlop

Ответы:

17

Я согласен с утверждением 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 существует, чтобы ответить на вопрос: учитывая сетевой ресурс, как мне его достичь? Он обрабатывает все детали, позволяя вам вернуться к программированию.

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

Петр Доброгост
источник
Что libproxy говорит о ваших вопросах? Тот, который меня интересует: «Должен ли .foo.example.com соответствовать foo.example.com или нет?»
Робин Уинслоу
Я понятия не имею. Я призываю вас спросить на github.com/libproxy/libproxy/issues
Петр Доброгост
13

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

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

BillThor
источник