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 વેબ સર્વરને તેની સ્ક્રિપ્ટમાં નામ આપેલા ફૉરવર્ડ પ્રોક્સીથી પણ અલગ પાડો. તેઓ એક મશીન શેર કરી શકે છે, પણ એક સેવાના એક્સેસ લોગમાંની નોંધ એ પુરાવો નથી કે બીજી સેવાએ વપરાશકર્તાની ગંતવ્ય વિનંતી સંભાળી હતી.