برای یک دستهٔ 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 می‌تواند هر دو فهرست قابل‌کاربرد را در همان یک درخواست ارسال‌شده به کار ببرد.

نشانگر مسیریابی مخصوص پروکسی به تبادل پروکسی تعلق دارد. در ارسال با متن ساده، یک فیلد سفارشی دلخواه می‌تواند به مبدأ برسد مگر اینکه ترتیب ارسال آن را مدیریت کند؛ نام گزینه تضمینی برای محرمانگی نیست.

برای احراز هویت از گزینه‌های اعتبارنامهٔ پشتیبانی‌شده استفاده کنید. برای فراداده‌های تعریف‌شده توسط اپراتور، مشخص کنید کدام گام آن را مصرف می‌کند و آیا می‌توان آن را ارسال کرد، به‌جای گذاشتن گذرواژه در یک فیلد عمومی.

وقتی نشانگری گم شده یا به نظر می‌رسد نشت کرده است، درخواست واقعی حاوی آن را شناسایی کنید. یک بازگشت فراخوان هدر که چند تبادل را نشان می‌دهد می‌تواند فهرست‌های درست‌جداشده را درهم‌آمیخته نشان دهد.

مقالات مرتبط