یک کلاینت سرویس تولیدشده می‌تواند هم نقطه پایانی سرویس و هم تنظیمات اتصال مرتبط با پروکسی داشته باشد. با مشخص کردن اینکه کدام نشانی به کدام نقش تعلق دارد شروع کنید. سرویس SOAP مقصد می‌ماند؛ ProxyAddress نام یک واسطه را می‌برد.

در BasicHttpBinding، گزینه UseDefaultWebProxy رفتار پروکسی پیکربندی‌شده خودکار را انتخاب می‌کند و به‌طور پیش‌فرض true است. قرارداد مایکروسافت ترکیب آن مقدار true با یک ProxyAddress صریح غیرتهی را پشتیبانی نمی‌کند. انتخاب را منسجم کنید، به‌جای اینکه هر دو را مقداردهی کنید و فرض کنید یکی بی‌صدا برنده می‌شود. برای سرویس SOAP با دسترسی عمومی روی مسیر پروکسی عمومی مجاز و بدون احراز هویت، فهرست پروکسی HTTP نشانی‌های کاندید برای ProxyAddress فراهم می‌کند؛ هیچ اعتبارنامه پروکسی از نقطه پایانی دیگری نگه ندارید.

اتصالی را که نقطه پایانی در واقع استفاده می‌کند بررسی کنید

یک تابع کمکی می‌تواند اتصال درست را بسازد در حالی که کلاینت تولیدشده هنوز از نقطه پایانی پیکربندی‌شده دیگری استفاده می‌کند. اتصال اختصاص‌یافته به فراخوانی ناموفق را بررسی کنید. تغییر یک ورودی پیکربندی که کلاینت هرگز انتخاب نکرده نمی‌تواند بر مسیر آن اثر بگذارد.

سپس نوع اعتبارنامه پروکسی را از نوع اعتبارنامه سرویس تفکیک کنید. گذرواژه‌ای که سرویس SOAP می‌خواهد به‌طور خودکار حساب واسطه شبکه انتخاب‌شده نیست.

حالت امنیت انتقال تصمیم دیگری است. جابه‌جایی به حالت فقط اعتبارنامه تنها به این دلیل که پاسخی قدیمی آن را پیشنهاد می‌کند، فرض‌های انتقال را تغییر می‌دهد؛ ثابت نمی‌کند که مسیر یا حساب درست است. TLS مقصد را حفظ کنید و از ترتیبات احراز هویتی استفاده کنید که کلاینت WCF مستقر و پروکسی پشتیبانی می‌کنند.

یک عیب‌یابی سودمند نقطه پایانی سرویس، منبع پروکسی انتخاب‌شده، نمونه اتصال و نخستین مرحله پاسخ را نام می‌برد. این خطای 407 را محدود می‌کند بدون آنکه کلاینت سرویس تولیدشده را به مجموعه‌ای از حدس‌های پیکربندی بی‌ربط تبدیل کند.

مقالات مرتبط