libproxy يختار المسار؛ عميلك ينشئ الاتصال
استخدم نتائج libproxy كمرشحات توجيه لكل عنوان URL بدلًا من توقع أن تعيد عملية الاكتشاف توجيه مقابس التطبيق.
إذا أعاد libproxy عنوان URI لوكيل بينما يتصل المقبس التالي مباشرة، فافحص عملية التسليم. يكتشف libproxy السياسة؛ لكنه لا يعترض كل مقبس يفتحه التطبيق.
- استعلم عن المورد. في واجهة libproxy 0.5 C API الموثقة، أنشئ مصنع وكيل واطلب عنوان URL الفعلي للوجهة.
- فسّر المرشحات المرتبة. تحتاج نتائج HTTP وSOCKS والنتائج المباشرة إلى معالجة مختلفة. حافظ على ترتيب أفضليتها وسياسة الفشل المقصودة.
- هيّئ المستهلك. أعطِ نوع الوكيل المختار ونقطة النهاية وترتيب المصادقة لنقل يدعمها. لا يكتسب مقبس TCP الخام تفاوض CONNECT أو SOCKS من عنوان URI مُعاد.
لا تحفظ إجابة واحدة كمسار لكل الوجهات ولا تجعل التوجيه المباشر دائمًا لأن الوكيل الأول فشل مرة واحدة.
إذا كان عميل HTTP يدمج بالفعل اكتشاف وكيل النظام أو PAC، فاختر مالكًا واحدًا للاختيار. قد ينتج منتقيان مستقلان مع غلاف آخر مسارًا لم تقصده أي من السياستين.
في الشيفرة الأصلية، اتبع دورة حياة المصنع وذاكرة النتائج الخاصة بواجهة API المثبتة. قد يحتفظ إعادة استخدام المصنع بحالة اكتشاف مفيدة، لكنه لا يزال يحتاج إلى استعلام لكل وجهة. سجّل الاختيار منفصلًا عن نتيجة الاتصال: فالعنوان URI المُعاد لا يثبت نجاح المصادقة أو التحليل أو الوصول اللاحق.