افصل رؤوس وكيل 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 استخدام كلتا القائمتين المناسبتين في الطلب المُعاد توجيهه الواحد. |
ينتمي علامة التوجيه الخاصة بالوكيل فقط إلى تبادل الوكيل. مع إعادة التوجيه بالنص العادي، يمكن لحقل مخصص عشوائي أن يصل إلى الأصل ما لم يتعامل ترتيب إعادة التوجيه معه؛ اسم الخيار ليس ضماناً للسرية.
استخدم خيارات بيانات الاعتماد المدعومة للمصادقة. بالنسبة للبيانات الوصفية التي يحددها المشغّل، حدّد أي قفزة تستهلكها وما إذا كان يجوز تمريرها بدلاً من وضع كلمة مرور في حقل عام.
عندما تكون العلامة مفقودة أو يبدو أنها تتسرب، حدّد الطلب الفعلي الذي يحتوي عليها. يمكن لرد نداء الرؤوس الذي يعرض عدة تبادلات أن يجعل القوائم المنفصلة بشكل صحيح تبدو مختلطة.