Аддзяліце проксі-загалоўкі libcurl ад загалоўкаў вэб-сайта
Дайце libcurl асобныя спісы загалоўкаў проксі і пункту прызначэння, прызнаючы, што перадача адкрытым тэкстам мае іншую мяжу бачнасці.
Для існуючага дэскрыптара libcurl явна аддзяліце спісы загалоўкаў пункту прызначэння і проксі:
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); Трымайце наладжаны дэскрыптар і сапраўдныя спісы жывымі на працягу перадачы. CURLHEADER_SEPARATE адрознівае загалоўкі, якія выкарыстоўваюцца на CONNECT, ад загалоўкаў, якія выкарыстоўваюцца для запыту да пункту прызначэння. Старэйшыя прыклады ўніфікаванай палітыкі могуць змяшчаць звычайны спіс у абодвух абменах.
| Шлях запыту | Значэнне асобных спісаў |
|---|---|
| HTTPS унутры звычайнага тунэлю CONNECT | Спачатку ідзе абмен з проксі; затым загалоўкі HTTP пункту прызначэння ідуць унутры TLS пункту прызначэння. |
| Звычайная перадача HTTP | Проксі можа чытаць загалоўкі пункту прызначэння, і libcurl можа выкарыстоўваць абодва адпаведныя спісы ў адным перададзеным запыце. |
Маркер маршрутызацыі толькі для проксі належыць да абмену з проксі. Пры перадачы адкрытым тэкстам адвольнае карыстальніцкае поле можа дасягнуць крыніцы, калі толькі схема перадачы не апрацоўвае яго; назва параметра не з'яўляецца гарантыяй канфідэнцыйнасці.
Выкарыстоўвайце падтрыманыя параметры ўліковых даных для аўтэнтыфікацыі. Для метаданых, вызначаных аператарам, усталюйце, які крок іх спажывае і ці можна іх перадаваць, замест таго каб змяшчаць пароль у агульнае поле.
Калі маркер адсутнічае або выглядае так, што ўцякае, вызначце фактычны запыт, які яго змяшчае. Зваротны выклік загалоўкаў, які паказвае некалькі абменаў, можа ствараць уражанне, што правільна аддзеленыя спісы змяшаліся.