Separate libcurl’s Proxy Headers from Website Headers
Give libcurl separate proxy and destination header lists, while recognizing that plaintext forwarding has a different visibility boundary.
For an existing libcurl handle, separate the destination and proxy header lists explicitly:
curl_easy_setopt(handle, CURLOPT_HEADEROPT, (long)CURLHEADER_SEPARATE);
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HTTPHEADER, origin_headers);Keep the configured handle and valid lists alive for the transfer. CURLHEADER_SEPARATE distinguishes headers used on CONNECT from headers used for the destination request. Older unified-policy examples can put the ordinary list in both exchanges.
| Request path | Meaning of separate lists |
|---|---|
| HTTPS inside an ordinary CONNECT tunnel | The proxy exchange comes first; destination HTTP headers follow inside destination TLS. |
| Plain HTTP forwarding | The proxy can read the destination headers, and libcurl can use both applicable lists on the one forwarded request. |
A proxy-only routing marker belongs on the proxy exchange. With plaintext forwarding, an arbitrary custom field can reach the origin unless the forwarding arrangement handles it; the option's name is no confidentiality guarantee.
Use supported credential options for authentication. For operator-defined metadata, establish which hop consumes it and whether it may be forwarded instead of putting a password in a generic field.
When a marker is missing or appears to leak, identify the actual request containing it. A header callback showing several exchanges can make correctly separated lists look mixed.