اسم wpad يُحلّ إلى الجهاز المتوقع. هذا مشجّع، لكنه مجرد البداية. ما زال على المتصفح أن يطلب ملفًا من ذلك الجهاز ويستلم سكربت PAC.

يمكن العثور على دليل مفيد في سجل وصول خادم الويب: طلب العميل /wpad.dat وتلقّى HTTP 404. قد يستخدم عنوان PAC المفتوح يدويًا اسم مضيف مختلفًا. وحتى عندما يصل الاسمان إلى الخادم نفسه، فقد يختاران مضيفين افتراضيين مختلفين.

تتبَّع الطلب الذي أرسله العميل

تحقق من عنوان URL الدقيق الذي اختاره الاكتشاف، وقيمة HTTP Host، والمسار، والاستجابة. فتح عنوان PAC مناسب في علامة تبويب عادية لا يثبت أن الاكتشاف التلقائي طلب ذلك العنوان.

إذا كان يُتوقع وجود أسماء قصيرة وأسماء مؤهلة بالكامل، فاضبط مضيف الويب المقصود للتعامل مع تلك الأسماء عن قصد. تأكد من أن /wpad.dat يشير إلى الملف الصحيح، لا إلى جذر مستندات افتراضي أو تطبيق غير ذي صلة.

قدِّم سكربتًا، لا صفحة خطأ

تحقق من جسم الاستجابة إلى جانب حالتها. قد تبدو صفحة تسجيل الدخول أو مستند خطأ بعلامة تجارية أو إعادة توجيه معقولة عند عرضها يدويًا، لكنها ليست سكربت PAC الذي يتوقعه المحلّل. توثّق Chromium متطلبات تنزيل PAC الصارمة، بما في ذلك استجابة HTTP 200.

بعد ينجح التسليم فقط يصبح تصحيح FindProxyForURL() منطقيًا. تغيير قواعد أسماء المضيفين فيه لا يمكن أن يصلح خطأ 404 منع المتصفح من الحصول عليه.

ميّز أيضًا بين خادم ويب PAC والوكيل الأمامي المسمّى داخل سكربته. قد يتشاركان الجهاز، لكن وجود قيد في سجل الوصول لدى خدمة ما ليس دليلًا على أن الخدمة الأخرى عالجت طلب الوجهة للمستخدم.

مقالات ذات صلة