Séparez les en-têtes de proxy de libcurl des en-têtes du site web
Donnez à libcurl des listes distinctes d'en-têtes de proxy et de destination, tout en reconnaissant que le transfert en texte clair a une limite de visibilité différente.
Pour un handle libcurl existant, séparez explicitement les listes d'en-têtes de destination et de proxy :
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);Gardez le handle configuré et les listes valides en vie pendant le transfert. CURLHEADER_SEPARATE distingue les en-têtes utilisés sur CONNECT des en-têtes utilisés pour la requête de destination. Les anciens exemples à politique unifiée peuvent placer la liste ordinaire dans les deux échanges.
| Chemin de la requête | Signification des listes séparées |
|---|---|
| HTTPS dans un tunnel CONNECT ordinaire | L'échange avec le proxy vient d'abord ; les en-têtes HTTP de destination suivent à l'intérieur du TLS de destination. |
| Transfert HTTP simple | Le proxy peut lire les en-têtes de destination, et libcurl peut utiliser les deux listes applicables sur l'unique requête transférée. |
Un marqueur de routage réservé au proxy appartient à l'échange avec le proxy. En transfert en texte clair, un champ personnalisé arbitraire peut atteindre l'origine, sauf si la disposition de transfert le gère ; le nom de l'option ne constitue pas une garantie de confidentialité.
Utilisez les options d'identifiants prises en charge pour l'authentification. Pour les métadonnées définies par l'opérateur, déterminez quel saut les consomme et si elles peuvent être transférées, au lieu de placer un mot de passe dans un champ générique.
Lorsqu'un marqueur manque ou semble fuir, identifiez la requête réelle qui le contient. Un rappel d'en-tête montrant plusieurs échanges peut faire paraître mélangées des listes correctement séparées.