موجودہ 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 پر استعمال ہونے والے ہیڈرز کو منزل کی درخواست کے لیے استعمال ہونے والے ہیڈرز سے الگ کرتا ہے۔ پرانی یکساں پالیسی کی مثالیں عام فہرست کو دونوں تبادلوں میں رکھ سکتی ہیں۔

درخواست کا راستہالگ فہرستوں کا مفہوم
عام CONNECT سرنگ کے اندر HTTPSپہلے پراکسی کا تبادلہ آتا ہے؛ پھر منزل کے HTTP ہیڈر منزل کے TLS کے اندر آتے ہیں۔
عام HTTP آگے بھیجناپراکسی منزل کے ہیڈر پڑھ سکتا ہے، اور libcurl ایک ہی آگے بھیجی گئی درخواست پر دونوں قابلِ اطلاق فہرستیں استعمال کر سکتا ہے۔

صرف پراکسی کے لیے روٹنگ مارکر پراکسی کے تبادلے سے تعلق رکھتا ہے۔ سادہ متن میں آگے بھیجنے پر، کوئی بھی حسبِ ضرورت کسٹم فیلڈ اصل تک پہنچ سکتا ہے جب تک کہ آگے بھیجنے کا انتظام اسے سنبھالے؛ اختیار کا نام رازداری کی ضمانت نہیں ہے۔

تصدیق کے لیے معاون اسناد کے اختیارات استعمال کریں۔ آپریٹر کے متعین میٹاڈیٹا کے لیے، طے کریں کہ کون سا ہاپ اسے استعمال کرتا ہے اور کیا عام فیلڈ میں پاس ورڈ رکھنے کے بجائے اسے آگے بھیجا جا سکتا ہے۔

جب مارکر غائب ہو یا رس رہا معلوم ہو، تو اسے رکھنے والی اصل درخواست کی نشاندہی کریں۔ کئی تبادلے دکھانے والا ہیڈر کال بیک درست طور پر الگ کی گئی فہرستوں کو ملا ہوا دکھا سکتا ہے۔

متعلقہ مضامین