WPAD ແກ້ໄຂໄດ້ ແຕ່ບຣາວເຊີໄດ້ຮັບ 404
ການຄົ້ນຫາພຣັອກຊີອັດຕະໂນມັດອາດພົບເຊີບເວີທີ່ຖືກຕ້ອງ ແຕ່ຍັງຮ້ອງຂໍໄຟລ໌ PAC ຈາກ virtual host ຫຼືເສັ້ນທາງທີ່ຜິດ.
ຊື່ wpad ແກ້ໄຂໄປຫາເຄື່ອງທີ່ຄາດໄວ້. ນັ້ນເປັນສິ່ງທີ່ໃຫ້ກຳລັງໃຈ ແຕ່ມັນເປັນພຽງຈຸດເລີ່ມຕົ້ນ. ບຣາວເຊີຍັງຕ້ອງຮ້ອງຂໍໄຟລ໌ຈາກເຄື່ອງນັ້ນ ແລະໄດ້ຮັບສະຄຣິບ PAC.
ມີເບາະແສທີ່ເປັນປະໂຫຍດຢູ່ໃນບັນທຶກການເຂົ້າເຖິງຂອງເຊີບເວີເວັບ: ລູກຂ່າຍໄດ້ຮ້ອງຂໍ /wpad.dat ແລະໄດ້ຮັບ HTTP 404. URL ຂອງ PAC ທີ່ເປີດດ້ວຍມືອາດໃຊ້ຊື່ໂຮສຕ໌ອື່ນ. ເຖິງແມ່ນວ່າທັງສອງຊື່ໄປຮອດເຊີບເວີດຽວກັນ ພວກມັນກໍອາດເລືອກ virtual host ທີ່ຕ່າງກັນ.
ຕິດຕາມຄຳຮ້ອງຂໍທີ່ລູກຂ່າຍສົ່ງມາ
ກວດເບິ່ງ URL ທີ່ແນ່ນອນທີ່ການຄົ້ນຫາເລືອກ, ຄ່າ HTTP Host, ເສັ້ນທາງ ແລະການຕອບສະໜອງ. ການເປີດ URL ຂອງ PAC ທີ່ສະດວກໃນແທັບບຣາວເຊີທຳມະດາບໍ່ໄດ້ພິສູດວ່າການຄົ້ນຫາອັດຕະໂນມັດໄດ້ຮ້ອງຂໍ URL ນັ້ນ.
ຖ້າຄາດຫວັງທັງຊື່ສັ້ນ ແລະຊື່ເຕັມທີ່ມີຄຸນນະພາບ ໃຫ້ຕັ້ງຄ່າໂຮສຕ໌ເວັບທີ່ຕັ້ງໃຈໄວ້ໃຫ້ຈັດການຊື່ເຫຼົ່ານັ້ນຢ່າງຕັ້ງໃຈ. ຢືນຢັນວ່າ /wpad.dat ຈົດຈຳໄປຫາໄຟລ໌ທີ່ຖືກຕ້ອງ ບໍ່ແມ່ນຮາກເອກະສານພື້ນຖານ ຫຼືແອັບພລິເຄຊັນທີ່ບໍ່ກ່ຽວຂ້ອງ.
ສະໜອງສະຄຣິບ ບໍ່ແມ່ນໜ້າຂໍ້ຜິດພາດ
ກວດສອບເນື້ອໃນການຕອບສະໜອງ ພ້ອມທັງສະຖານະຂອງມັນ. ໜ້າເຂົ້າສູ່ລະບົບ, ເອກະສານຂໍ້ຜິດພາດທີ່ມີແບຣນ ຫຼືການປ່ຽນເສັ້ນທາງອາດເບິ່ງໜ້າເຊື່ອຖືເມື່ອເບິ່ງດ້ວຍມື ແຕ່ມັນບໍ່ແມ່ນສະຄຣິບ PAC ທີ່ຕົວແກ້ຄາດຫວັງ. Chromium ເອກະສານ ຂໍ້ກຳນົດການດາວໂຫຼດ PAC ທີ່ເຂັ້ມງວດ ລວມທັງການຕອບສະໜອງ HTTP 200.
ຫຼັງຈາກ ການສົ່ງມອບສຳເລັດ ແລ້ວຈຶ່ງມີຄວາມໝາຍທີ່ຈະດີບັກ FindProxyForURL(). ການປ່ຽນກົດຊື່ໂຮສຕ໌ຂອງມັນບໍ່ສາມາດແກ້ໄຂ 404 ທີ່ເຮັດໃຫ້ບຣາວເຊີບໍ່ໄດ້ຮັບມັນ.
ຍັງແຍກເຊີບເວີເວັບ PAC ອອກຈາກພຣັອກຊີສົ່ງຕໍ່ທີ່ກ່າວເຖິງໃນສະຄຣິບຂອງມັນ. ພວກມັນອາດໃຊ້ເຄື່ອງດຽວກັນ ແຕ່ລາຍການໃນບັນທຶກການເຂົ້າເຖິງຂອງບໍລິການໜຶ່ງບໍ່ແມ່ນຫຼັກຖານວ່າອີກບໍລິການໜຶ່ງໄດ້ຈັດການຄຳຮ້ອງຂໍປາຍທາງຂອງຜູ້ໃຊ້.