WPAD حل ہو جاتا ہے، لیکن براؤزر کو 404 ملتا ہے

wpad نام متوقع مشین پر حل ہوتا ہے۔ یہ حوصلہ افزا ہے، لیکن یہ صرف آغاز ہے۔ براؤزر کو اب بھی اُس مشین سے فائل طلب کرنی ہے اور PAC اسکرپٹ حاصل کرنا ہے۔

ایک مفید سراغ ویب سرور کے رسائی لاگ میں ملتا ہے: کلائنٹ نے /wpad.dat طلب کیا اور HTTP 404 حاصل کیا۔ دستی طور پر کھولا گیا PAC URL کوئی دوسرا ہوسٹ نام استعمال کر سکتا ہے۔ دونوں نام ایک ہی سرور تک پہنچنے پر بھی مختلف ورچوئل ہوسٹ منتخب کر سکتے ہیں۔

کلائنٹ کی بھیجی گئی درخواست کی پیروی کریں

دریافت کے منتخب کردہ درست URL، HTTP Host ویلیو، راستے اور جواب کی جانچ کریں۔ عام براؤزر ٹیب میں سہولت بخش PAC URL کھولنا یہ ثابت نہیں کرتا کہ خودکار دریافت نے وہی URL طلب کیا تھا۔

اگر مختصر اور مکمل طور پر اہل دونوں نام متوقع ہیں تو مطلوبہ ویب ہوسٹ کو ان ناموں کو دانستہ طور پر سنبھالنے کے لیے ترتیب دیں۔ تصدیق کریں کہ /wpad.dat صحیح فائل پر نقش ہوتا ہے، نہ کہ ڈیفالٹ دستاویز روٹ یا غیر متعلق ایپلیکیشن پر۔

ایرر صفحہ نہیں، اسکرپٹ فراہم کریں

جواب کی حیثیت کے ساتھ اس کے متن کی بھی تصدیق کریں۔ سائن اِن صفحہ، برانڈڈ ایرر دستاویز یا ری ڈائریکٹ دستی طور پر دیکھنے میں معتبر لگ سکتے ہیں، لیکن یہ وہ PAC اسکرپٹ نہیں جو حل کنندہ توقع کرتا ہے۔ Chromium سخت PAC ڈاؤن لوڈ کی شرائط کی دستاویز کرتا ہے، بشمول HTTP 200 جواب۔

ترسیل کامیاب ہونے کے بعد کے بعد ہی FindProxyForURL() کی ڈیبگ کرنا معنی رکھتا ہے۔ اس کے ہوسٹ نام کے قواعد بدلنے سے وہ 404 درست نہیں ہو سکتا جس نے براؤزر کو اسے حاصل کرنے سے روکا۔

PAC ویب سرور کو اس کے اسکرپٹ میں نامزد فارورڈ پراکسی سے بھی الگ پہچانیں۔ وہ ایک مشین شیئر کر سکتے ہیں، لیکن ایک سروس کے رسائی لاگ میں درج اندراج اس بات کا ثبوت نہیں کہ دوسری سروس نے صارف کی منزل کی درخواست سنبھالی۔