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 ਵੈੱਬ ਸਰਵਰ ਨੂੰ ਇਸ ਦੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਨਾਮਿਤ ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਤੋਂ ਵੀ ਵੱਖਰਾ ਸਮਝੋ। ਉਹ ਇੱਕ ਮਸ਼ੀਨ ਸਾਂਝੀ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਸੇਵਾ ਦੇ ਐਕਸੈਸ ਲੌਗ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਦੂਜੀ ਸੇਵਾ ਨੇ ਵਰਤੋਂਕਾਰ ਦੀ ਮੰਜ਼ਿਲ ਬੇਨਤੀ ਸੰਭਾਲੀ।