هدرهای پروکسی 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 میتواند هر دو فهرست قابلکاربرد را در همان یک درخواست ارسالشده به کار ببرد. |
نشانگر مسیریابی مخصوص پروکسی به تبادل پروکسی تعلق دارد. در ارسال با متن ساده، یک فیلد سفارشی دلخواه میتواند به مبدأ برسد مگر اینکه ترتیب ارسال آن را مدیریت کند؛ نام گزینه تضمینی برای محرمانگی نیست.
برای احراز هویت از گزینههای اعتبارنامهٔ پشتیبانیشده استفاده کنید. برای فرادادههای تعریفشده توسط اپراتور، مشخص کنید کدام گام آن را مصرف میکند و آیا میتوان آن را ارسال کرد، بهجای گذاشتن گذرواژه در یک فیلد عمومی.
وقتی نشانگری گم شده یا به نظر میرسد نشت کرده است، درخواست واقعی حاوی آن را شناسایی کنید. یک بازگشت فراخوان هدر که چند تبادل را نشان میدهد میتواند فهرستهای درستجداشده را درهمآمیخته نشان دهد.