WCF BasicHttpBinding: ProxyAddress و UseDefaultWebProxy

قد يمتلك عميل خدمة مُولَّد نقطة نهاية خدمة وإعدادات ربط متعلقة بالوكيل في الوقت نفسه. ابدأ بتحديد أي عنوان ينتمي إلى أي دور. تبقى خدمة SOAP هي الوجهة، بينما يسمّي ProxyAddress وسيطًا.

في BasicHttpBinding يختار UseDefaultWebProxy سلوك الوكيل المُهيَّأ تلقائيًا، وقيمته الافتراضية true. لا يدعم عقد Microsoft الجمع بين قيمة true هذه وعنوان ProxyAddress صريح غير فارغ. اجعل الخيار متسقًا بدلًا من تعيين الاثنين معًا والافتراض بأن أحدهما يفوز بصمت. لخدمة SOAP يمكن الوصول إليها علنًا عبر مسار وكيل عام غير مُصادَق عليه ومسموح به، توفّر قائمة وكلاء HTTP عناوين مرشحة لـ ProxyAddress؛ ولا تحتفظ بأي بيانات اعتماد وكيل من نقطة نهاية أخرى.

تحقّق من الربط الذي تستخدمه نقطة النهاية فعليًا

قد تبني دالة مساعدة الربط الصحيح بينما لا يزال العميل المُولَّد يستخدم نقطة نهاية أخرى مُهيَّأة. افحص الربط المُسنَد إلى الاستدعاء الفاشل. لا يمكن لتغيير إدخال تهيئة لم يختره العميل قط أن يؤثر في مساره.

ثم ميّز نوع بيانات اعتماد الوكيل من نوع بيانات اعتماد الخدمة. كلمة المرور التي تطلبها خدمة SOAP ليست تلقائيًا حسابًا للوسيط الشبكي المختار.

وضع أمان النقل قرار آخر. الانتقال إلى وضع الاعتماد فقط لمجرد أن إجابة قديمة تقترح ذلك يغيّر افتراضات النقل؛ وهو لا يثبت أن المسار أو الحساب صحيح. حافظ على TLS المقصود للوجهة واستخدم ترتيب المصادقة الذي يدعمه عميل WCF المنشور والوكيل.

التشخيص المفيد يسمّي نقطة نهاية الخدمة ومصدر الوكيل المختار ومثيل الربط ومرحلة الاستجابة الأولى. يضيّق ذلك خطأ 407 دون تحويل عميل خدمة مُولَّد إلى مجموعة تخمينات تهيئة غير مترابطة.