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 वेब सर्वर को उसकी स्क्रिप्ट में नामित फ़ॉरवर्ड प्रॉक्सी से भी अलग पहचानें। वे एक मशीन साझा कर सकते हैं, पर एक सेवा के एक्सेस लॉग की प्रविष्टि इस बात का प्रमाण नहीं है कि दूसरी सेवा ने उपयोगकर्ता के गंतव्य अनुरोध को संभाला।