Чи змінні середовища HTTP_PROXY, HTTPS_PROXY та NO_PROXY?

Здається, що багато програм призначені для читання цих змінних середовища, щоб вирішити, через який проксі потрібно пройти, щоб підключитися до ресурсу в Інтернеті. Ці програми також можуть мати власні індивідуальні настройки проксі, але якщо їх не встановлено, вони із задоволенням використовуватимуть ці змінні середовища ...

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

Я лише хочу знати:

• Чи є ці змінні середовища стандартними?
• Чи є письмова специфікація (може бути виробниками ОС?), Яка рекомендує використовувати ці змінні середовища?

Я погоджуюся з твердженням БілТхора, що це скоріше конвенція, ніж стандарт.
Я не знаю походження цих змінних, але у випадку HTTP на * nix багато конвенцій, схоже, походять від поведінки бібліотеки HTTP libcurl та програми командного рядка 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 з провідною точкою не оброблені належним чином і пов'язане з цим питанням - Python 2.7.13 не поважає NO_PROXY і робить помилку urllib2.urlopen () з "З'єднанням тунелю не вдалося: 403 заборонено"

Це скоріше умова, ніж стандарт. Ймовірно, це підтримується однією або декількома бібліотеками обробників протоколів, які фактично здійснюють з'єднання. Java використовує подібні властивості у своїх бібліотеках протоколів.

Розуміння та використання загальних конвенцій робить розвиток набагато простішим. Це також допомагає реалізувати принцип найменшого здивування та зробити програми більш імовірними just work.