在 CONNECT 请求中保留代理 Cookie

有些代理产品定义了登录流程，为后续代理请求提供 Cookie 或令牌。如果该令牌必须出现在 CONNECT 上，请把它与隧道内网站使用的 Cookie 分开。

libcurl 为代理提供了专用的自定义头列表。在已初始化的 C 应用中，配置片段可以如下所示：

struct curl_slist *proxy_headers = NULL;
proxy_headers = curl_slist_append(proxy_headers,
    "Cookie: ProxySession=REPLACE_WITH_PROXY_TOKEN");
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HEADEROPT,
                 (long) CURLHEADER_SEPARATE);

仅当代理文档化的登录协议要求该头时才应这样做。在周边代码中检查分配与选项的返回值，在传输完成前一直保留该列表，然后在释放列表前清除或替换句柄的指针。

采用分离的头处理后，libcurl 在 CONNECT 上发送代理列表，在已建立隧道内的请求上发送目标列表。因此代理能收到供应商令牌，而该令牌不会成为网站 Cookie。这种分离自 libcurl 7.42.1 起就是默认行为；显式选项让预期行为可见。

浏览器 Cookie 罐是另一种机制

启用 libcurl 的 Cookie 引擎或为目标设置 Cookie 并不会自动复现浏览器专有的代理登录流程。CONNECT 发生在与目标的 HTTPS 交换之前。应确认产品的实际要求，而不是把抓取到的站点 Cookie 复制到每个请求中。

如果代理使用标准 HTTP 代理认证，请改用 libcurl 的代理凭据和受支持的认证选项。带有 Proxy-Authenticate 的 407 与返回会话令牌的 HTML 登录页是不同的协议。

将令牌限制在其代理端点和预期生命周期内。切换到其他中间人时，应作为该配置变更的一部分替换头列表。通用请求头列表并不适合存放只属于某一个代理的机密。