☰

HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 环境变量是标准的吗？

tag-icon • tag-icon environment-variables http http-proxy
HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 环境变量是标准的吗？

似乎很多程序都被设计为读取这些环境变量，以决定通过哪个代理来连接到互联网上的资源。这些程序可能也有自己的单独代理设置，但如果没有设置，它们会很乐意使用这些环境变量...

  • HTTP_代理
  • HTTPS_代理
  • 无代理

我只是想知道：

  • 这些环境变量是标准的吗？
  • 是否有书面规范（可能是由操作系统制造商制定的？）建议使用这些环境变量？

答案1

我同意 BillThor 的说法这更像是一种惯例，而不是标准。
我不知道这些变量的来源，但在 *nix 上的 HTTP 中，许多约定似乎源自库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 的存在是为了回答这个问题：给定一个网络资源，我如何访问它？它处理所有细节，使您能够重新进行编程。

进一步阅读：

答案2

没有真正的标准。

不同的工具对这些变量的解释类似，但又略有不同。例如案件已识别的环境变量和案例优先在不同工具curl和wgetRuby、Python、Go 等语言之间有所差异：（此表取自优秀文章我们需要讨论：我们可以标准化 NO_PROXY 吗？）

  curl wget 红宝石 Python 去
http_proxy（小写） 是的 是的 是的 是的 是的
HTTP_PROXY（大写） 不 不 是（警告） 是（如果 REQUEST_METHOD 不在环境中） 是的
https_proxy（小写） 是的 是的 是的 是的 是的
HTTPS_PROXY（大写） 是的 不 是的 是的 是的
no_proxy （小写） 是的 是的 是的 是的 是的
NO_PROXY （大写） 是的 不 是的 是的 是的
案例优先 小写 仅限小写 小写 小写 大写

有关更多详细信息（特别是有关 NO_PROXY 变​​量）和一些历史记录，请参阅上述完整文章。

答案3

这更像是一种惯例，而不是标准。它可能得到一个或多个实际建立连接的协议处理程序库的支持。Java 在其协议库中使用了类似的属性。

理解和使用通用约定可使开发变得简单得多。它还有助于实现最小意外原则，并使程序更有可能just work。

相关内容