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