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