【发布时间】:2020-09-29 09:49:53
【问题描述】:
在节点https module docs中, 关于https.request,举个例子:
const options = {
hostname: 'encrypted.google.com',
port: 443,
path: '/',
method: 'GET',
key: fs.readFileSync('test/fixtures/keys/agent2-key.pem'),
cert: fs.readFileSync('test/fixtures/keys/agent2-cert.pem')
};
options.agent = new https.Agent(options);
const req = https.request(options, (res) => {
// ...
});
在我看来,这个例子有点模棱两可,我问了一个SO question regarding this ambiguity,并在评论后重申了奇怪的措辞opened an issue for this。
无论如何,我仍在尝试了解代理在这种情况下所扮演的角色,因为 https.Agent 模块确实接受 TLS 连接选项:
interface AgentOptions extends http.AgentOptions, tls.ConnectionOptions
https.Agent对象的定义是:
HTTPS 的代理对象,类似于 http.Agent。
http.Agent 对象的定义是:
代理负责管理 HTTP 客户端的连接持久性和重用。
据我了解,代理“负责”管理连接 - 显然,https.Agent 存在于“普通”http.Agent 之上的事实意味着它“负责”管理 HTTPS 连接 - 因此它可能会收到 TLS 配置选项。
我的问题是——这是否意味着在这种情况下代理有额外的责任来配置请求的网络安全?如果这是真的,这是一个奇怪的 API - 我本来希望在 https.request 的单独密钥上看到网络连接配置(如上面 sn-p 之后的示例所示)。为什么要为另一个职责重载同一个对象?真的,为什么有一个 https.Agent 呢? http.Agent 应该控制连接池和保持连接活动,而另一层应该控制配置实际请求。 https.Agent 对象对我来说似乎没有明确定义。
【问题讨论】: