Отделете прокси заглавията на 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 може да използва и двата приложими списъка в едната препратена заявка. |
Маркерът за маршрутизиране само през прокси принадлежи към обмена с проксито. При препращане с открит текст произволно персонализирано поле може да достигне до източника, освен ако схемата за препращане не се справя с него; името на опцията не е гаранция за поверителност.
Използвайте поддържани опции за идентификационни данни при удостоверяване. За метаданни, определени от оператора, установете кой хоп ги консумира и дали могат да бъдат препращани, вместо да поставяте парола в общо поле.
Когато маркерът липсва или изглежда, че изтича, идентифицирайте действителната заявка, която го съдържа. Обратно извикване за заглавия, което показва няколко обмена, може да създаде впечатление, че правилно разделените списъци са смесени.