HTTP 407 بدون چالش قابل استفاده Proxy-Authenticate
سرآیند احراز هویت پروکسی را بررسی کنید وقتی کلاینت هرگز کنترل‌کننده اعتبارنامه خود را فراخوانی نمی‌کند یا به جای چالش عادی وضعیت غیرمنتظره‌ای دریافت می‌کند.
کلاینت نمی‌تواند فقط از روی شماره وضعیت یک سازوکار احراز هویت انتخاب کند. پاسخ پروکسی باید توصیف کند که چه چیزی را می‌پذیرد.
HTTP از پروکسی‌ای که 407 تولید می‌کند می‌خواهد چالش Proxy-Authenticate بفرستد. برای سرویس Basic یک نمونه ساده چنین است:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"وضعیت عددی، نام سرآیند و نحو مخصوص هر طرح همگی مهم‌اند. صفحه خطای برندشده‌ای که واژه authentication در متن آن باشد جایگزین سرآیند نیست. پیاده‌سازی‌های سفارشی نیز باید پاسخ کامل HTTP 407 را بفرستند، از جمله پایان‌دهنده سرآیند و قالب‌بندی بدنه.
پاسخی را که به این کلاینت رسیده بررسی کنید
پس از حذف مقادیر محرمانه، فیلدهای وضعیت و چالش را ثبت کنید. ممکن است یک واسطه پاسخ را تغییر داده باشد، یا پروکسی سفارشی چالش نامعتبری ساخته باشد. آن شواهد را با گزارش تراکنش خود پروکسی مقایسه کنید.
اگر سرویس در عوض 405 یا خطای دیگری بفرستد، هر چنین پاسخی را در یک کلاینت سفارشی به 407 برچسب نزنید. با این کار شکست‌های واقعی سیاست متد را پنهان می‌کنید و باز هم مذاکره مطمئن درباره طرح نخواهید داشت. رفتار سرویس را اصلاح کنید یا از مسیر احراز هویت پشتیبانی‌شده و مستند آن استفاده کنید.
چالش‌های متعدد به تحلیلگر واقعی HTTP هم نیاز دارند. یک ویرگول می‌تواند پارامترها یا چالش‌ها را جدا کند؛ تقسیم کورکورانه کل سرآیند بر ویرگول می‌تواند realm داخل گیومه را خراب کند. به جای زنجیره‌ای از جایگزینی رشته‌ها، از پیاده‌سازی احراز هویت پشتیبانی‌شده کلاینت استفاده کنید.
تنها پس از آنکه چالش قابل استفاده شد، بررسی این که چرا ارائه‌دهنده اعتبارنامه حسابی برنگرداند معنا پیدا می‌کند.