Sind die Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY Standard?


24

Anscheinend sind viele Programme darauf ausgelegt, diese Umgebungsvariablen zu lesen, um zu entscheiden, welcher Proxy durchlaufen werden soll, um eine Verbindung zu einer Ressource im Internet herzustellen. Diese Programme können auch ihre eigenen, individuellen Proxy-Einstellungen haben, aber wenn diese nicht festgelegt sind, werden sie diese Umgebungsvariablen gerne verwenden ...

  • HTTP-PROXY
  • HTTPS_PROXY
  • KEIN VERTRETER

Ich will nur wissen:

  • Sind diese Umgebungsvariablen Standard?
  • Gibt es eine schriftliche Spezifikation (möglicherweise von den Betriebssystemherstellern?), Die die Verwendung dieser Umgebungsvariablen empfiehlt?

1
Ich kenne no_proxy nicht, aber http_proxy (in Kleinbuchstaben) ist Standard
Uwe Burger

@UweBurger vielleicht kannst du angeben, welche Programme es verwenden .. Und das gilt auch für den Fragesteller. Ich habe gesehen, wie es am wget
barlop 25.07.15

Antworten:


16

Ich stimme der Aussage von BillThor zu, dass dies eher eine Konvention als ein Standard ist.
Ich kenne den Ursprung dieser Variablen nicht, aber im Falle von HTTP unter * nix scheinen viele Konventionen vom Verhalten der libcurl- HTTP-Bibliothek und des curl-Befehlszeilenprogramms zu herrühren .

Unter https://curl.haxx.se/docs/manual.html finden Sie eine Beschreibung der Umgebungsvariablen für die Verwendung von HTTP-Proxy, die von libcurl / curl verstanden werden:

UMGEBUNGSVARIABLEN

Curl liest und versteht die folgenden Umgebungsvariablen:
http_proxy, HTTPS_PROXY, FTP_PROXY

Sie sollten für protokollspezifische Proxys festgelegt werden. General Proxy sollte mit gesetzt werden
ALL_PROXY

Eine durch Kommas getrennte Liste von Hostnamen, die keinen Proxy durchlaufen sollen, ist eingestellt (nur ein Sternchen, '*' stimmt mit allen Hosts überein).
NO_PROXY

Wenn der Hostname mit einer dieser Zeichenfolgen übereinstimmt oder sich der Host in der Domäne einer dieser Zeichenfolgen befindet, werden Transaktionen mit diesem Knoten nicht weitergeleitet.

Bitte beachten Sie, dass http_proxyals einzige dieser Variablen Kleinbuchstaben verwendet werden. Einige Bibliotheken / Programme suchen nach Kleinbuchstaben dieser Variablen, während andere nach Großbuchstaben suchen. Zur Sicherheit sollte man für jede Variable sowohl Klein- als auch Großbuchstaben definieren.

Ein weiteres Problem ist, dass die zitierte Beschreibung, wie Hostnamen abgeglichen werden, NO_PROXYnicht genau ist und die folgenden Fragen nicht beantwortet:

  • Sollten Werte vollqualifizierte Domänennamen (FQDN) sein, die mit einem Punkt enden, foo.example.com.oder nicht?
  • Sollte foo.example.comnur diese eine Domain passen oder sollte es auch zu irgendeiner Subdomain passen wie bar.foo.example.com? Wenn letzteres dann sollte es auch mit irgendeiner Subdomain in irgendeiner Subdomain wie übereinstimmen bar.baz.foo.example.com?
  • Ist .foo.example.com(Punkt am Anfang) erlaubt und wenn ja, was soll es passen?
  • Ist asterisk ( *) als Teil von value ( *.example.com, ) erlaubt *example.comund wenn ja, wie wird es behandelt?

Mangelnde formale Spezifikation führt zu Verwirrung und Fehlern. Hier ist die libproxy- Bibliothek zu nennen, die die Proxy-Konfiguration korrekt und konsistent unterstützen soll. Von der Homepage des Projekts :

libproxy gibt es, um die Frage zu beantworten: Wie erreiche ich eine Netzwerkressource? Hier werden alle Details behandelt, sodass Sie wieder zur Programmierung zurückkehren können.

Weitere Lektüre:


Was sagt libproxy zu den von Ihnen aufgeworfenen Fragen? Die, die mich interessiert: "Sollte .foo.example.com mit foo.example.com übereinstimmen oder nicht?"
Robin Winslow

Ich habe keine Ahnung. Ich ermutige Sie, bei github.com/libproxy/libproxy/issues
Piotr Dobrogost

13

Dies ist eher eine Konvention als ein Standard. Es wird wahrscheinlich von einer oder mehreren Protokoll-Handler-Bibliotheken unterstützt, die tatsächlich die Verbindungen herstellen. Java verwendet ähnliche Eigenschaften in seinen Protokollbibliotheken.

Das Verstehen und Verwenden gemeinsamer Konventionen vereinfacht die Entwicklung erheblich. Es hilft auch, das Prinzip der geringsten Überraschung umzusetzen und die Wahrscheinlichkeit von Programmen zu erhöhen just work.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.