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 पर उपयोग किए जाने वाले हेडर को गंतव्य अनुरोध के लिए उपयोग किए जाने वाले हेडर से अलग करता है। पुराने एकीकृत-नीति उदाहरण सामान्य सूची को दोनों आदान-प्रदानों में रख सकते हैं।
| अनुरोध पथ | अलग सूचियों का अर्थ |
|---|---|
| सामान्य CONNECT सुरंग के भीतर HTTPS | प्रॉक्सी आदान-प्रदान पहले आता है; फिर गंतव्य HTTP हेडर गंतव्य TLS के भीतर आते हैं। |
| सामान्य HTTP अग्रेषण | प्रॉक्सी गंतव्य हेडर पढ़ सकता है, और libcurl एक अग्रेषित अनुरोध पर दोनों लागू सूचियों का उपयोग कर सकता है। |
केवल-प्रॉक्सी रूटिंग मार्कर प्रॉक्सी आदान-प्रदान पर आता है। सादे टेक्स्ट अग्रेषण में, एक मनमाना कस्टम फ़ील्ड मूल तक पहुँच सकता है जब तक कि अग्रेषण व्यवस्था इसे संभाले नहीं; विकल्प का नाम गोपनीयता की गारंटी नहीं है।
प्रमाणीकरण के लिए समर्थित क्रेडेंशियल विकल्पों का उपयोग करें। ऑपरेटर-परिभाषित मेटाडेटा के लिए, निर्धारित करें कि कौन-सा हॉप इसे उपभोग करता है और क्या सामान्य फ़ील्ड में पासवर्ड रखने के बजाय इसे अग्रेषित किया जा सकता है।
जब मार्कर गायब हो या लीक होता प्रतीत हो, तो उसे रखने वाले वास्तविक अनुरोध की पहचान करें। कई आदान-प्रदान दिखाने वाला हेडर कॉलबैक सही ढंग से अलग की गई सूचियों को मिश्रित दिखा सकता है।