14

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

  • HTTP_PROXY
  • https_proxy
  • no_proxy

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

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

2 ответа2

7

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

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

6

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .