Keeping a Proxy Cookie on the CONNECT Request

Use libcurl’s separate proxy-header interface for a vendor-defined CONNECT login instead of treating a destination cookie as proxy authentication.

Some proxy products define a login flow that supplies a cookie or token for subsequent proxy requests. If that token must appear on CONNECT, keep it separate from cookies intended for the website inside the tunnel.

libcurl provides a dedicated custom-header list for the proxy. In an already initialized C application, a configuration fragment can look like this:

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);

This is appropriate only when the proxy’s documented login protocol calls for that header. Check allocation and option results in the surrounding code, retain the list until the transfer has completed, then clear or replace the handle’s pointer before freeing the list.

With separate header handling, libcurl sends the proxy list on CONNECT and the destination list on the request inside the established tunnel. The proxy therefore receives the vendor token without that token becoming a website cookie. This separation is the default from libcurl 7.42.1; the explicit option makes the intended behavior visible.

A browser cookie jar is another mechanism

Enabling libcurl’s cookie engine or setting a cookie for the destination does not automatically reproduce a browser’s proprietary proxy-login workflow. CONNECT happens before the destination’s HTTPS exchange. Identify the product’s actual requirements rather than copying a captured site cookie into every request.

If the proxy uses standard HTTP proxy authentication, use libcurl’s proxy credentials and supported authentication options instead. A 407 with Proxy-Authenticate is a different protocol from an HTML login page returning a session token.

Keep the token scoped to its proxy endpoint and intended lifetime. When changing to another intermediary, replace the header list as part of that configuration change. A general request-header list is a poor place for a secret that belongs only to one proxy.

Artiglyn mynjee