WPAD പരിഹരിക്കുന്നു, പക്ഷേ ബ്രൗസറിന് 404 ലഭിക്കുന്നു
സ്വയമേവയുള്ള പ്രോക്സി കണ്ടെത്തൽ ശരിയായ സെർവർ കണ്ടെത്തിയാലും തെറ്റായ വെർച്വൽ ഹോസ്റ്റിൽ നിന്നോ പാതയിൽ നിന്നോ PAC ഫയൽ ആവശ്യപ്പെട്ടേക്കാം.
wpad എന്ന നാമം പ്രതീക്ഷിച്ച യന്ത്രത്തിലേക്ക് പരിഹരിക്കുന്നു. അത് പ്രോത്സാഹജനകമാണ്, പക്ഷേ അത് തുടക്കം മാത്രമാണ്. ആ യന്ത്രത്തിൽ നിന്ന് ഫയൽ ആവശ്യപ്പെട്ട് PAC സ്ക്രിപ്റ്റ് സ്വീകരിക്കേണ്ടത് ബ്രൗസറിന് ഇനിയും ബാക്കിയുണ്ട്.
വെബ് സെർവറിന്റെ ആക്സസ് ലോഗിൽ ഉപയോഗപ്രദമായ സൂചനയുണ്ട്: ക്ലയന്റ് /wpad.dat ആവശ്യപ്പെട്ടു, HTTP 404 ലഭിച്ചു. കൈകൊണ്ട് തുറന്ന PAC URL മറ്റൊരു ഹോസ്റ്റ്നെയിം ഉപയോഗിച്ചേക്കാം. രണ്ട് പേരുകളും ഒരേ സെർവറിൽ എത്തിയാലും അവ വ്യത്യസ്ത വെർച്വൽ ഹോസ്റ്റുകൾ തിരഞ്ഞെടുത്തേക്കാം.
ക്ലയന്റ് നടത്തിയ അഭ്യർത്ഥന പിന്തുടരുക
കണ്ടെത്തൽ തിരഞ്ഞെടുത്ത കൃത്യമായ URL, HTTP Host മൂല്യം, പാത, പ്രതികരണം എന്നിവ പരിശോധിക്കുക. സാധാരണ ബ്രൗസർ ടാബിൽ സൗകര്യപ്രദമായ PAC URL തുറക്കുന്നത് സ്വയമേവയുള്ള കണ്ടെത്തൽ ആ URL ആവശ്യപ്പെട്ടു എന്ന് തെളിയിക്കുന്നില്ല.
ചെറിയതും പൂർണ്ണയോഗ്യതയുള്ളതുമായ പേരുകൾ പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, ഉദ്ദേശിച്ച വെബ് ഹോസ്റ്റ് ആ പേരുകൾ ബോധപൂർവം കൈകാര്യം ചെയ്യാൻ ക്രമീകരിക്കുക. /wpad.dat ശരിയായ ഫയലിലേക്കാണ് മാപ്പ് ചെയ്യുന്നതെന്ന് ഉറപ്പാക്കുക, സ്ഥിരസ്ഥിതി ഡോക്യുമെന്റ് റൂട്ടിലേക്കോ ബന്ധമില്ലാത്ത ആപ്ലിക്കേഷനിലേക്കോ അല്ല.
പിശക് പേജല്ല, സ്ക്രിപ്റ്റ് നൽകുക
പ്രതികരണത്തിന്റെ അവസ്ഥയും ഉള്ളടക്കവും പരിശോധിക്കുക. സൈൻ-ഇൻ പേജ്, ബ്രാൻഡഡ് പിശക് രേഖ അല്ലെങ്കിൽ റീഡയറക്ട് എന്നിവ കൈകൊണ്ട് കാണുമ്പോൾ വിശ്വസനീയമായി തോന്നാം, പക്ഷേ അത് റിസോൾവർ പ്രതീക്ഷിക്കുന്ന PAC സ്ക്രിപ്റ്റ് അല്ല. Chromium കർശനമായ PAC ഡൗൺലോഡ് ആവശ്യകതകൾ രേഖപ്പെടുത്തുന്നു, HTTP 200 പ്രതികരണം ഉൾപ്പെടെ.
ഡെലിവറി വിജയിച്ച ശേഷം ശേഷം മാത്രമേ FindProxyForURL() ഡീബഗ് ചെയ്യുന്നതിൽ അർത്ഥമുള്ളൂ. അതിന്റെ ഹോസ്റ്റ്നെയിം നിയമങ്ങൾ മാറ്റുന്നത് ബ്രൗസറിന് അത് ലഭിക്കുന്നതിൽ നിന്ന് തടഞ്ഞ 404 പരിഹരിക്കാൻ കഴിയില്ല.
PAC വെബ് സെർവറിനെ അതിന്റെ സ്ക്രിപ്റ്റിൽ പേരിട്ട ഫോർവേഡ് പ്രോക്സിയിൽ നിന്ന് വേർതിരിക്കുകയും ചെയ്യുക. അവ ഒരേ യന്ത്രം പങ്കിട്ടേക്കാം, പക്ഷേ ഒരു സേവനത്തിന്റെ ആക്സസ് ലോഗിലെ ഒരു എൻട്രി മറ്റേ സേവനം ഉപയോക്താവിന്റെ ലക്ഷ്യ അഭ്യർത്ഥന കൈകാര്യം ചെയ്തു എന്നതിന് തെളിവല്ല.