HTTP 407 ໂດຍບໍ່ມີຄຳທ້າທາຍ Proxy-Authenticate ທີ່ໃຊ້ໄດ້

ໂປຣແກຣມລູກຄ້າບໍ່ສາມາດເລືອກກົນໄກການພິສູດຕົວຕົນຈາກພຽງແຕ່ໝາຍເລກສະຖານະໄດ້. ການຕອບສະໜອງຂອງພຣັອກຊີຕ້ອງອະທິບາຍວ່າມັນຍອມຮັບຫຍັງ.

HTTP ຮຽກຮ້ອງໃຫ້ພຣັອກຊີທີ່ສ້າງ 407 ສົ່ງຄຳທ້າທາຍ Proxy-Authenticate. ສຳລັບບໍລິການ Basic ຕົວຢ່າງງ່າຍໆແມ່ນ:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

ສະຖານະເປັນຕົວເລກ, ຊື່ຫົວຂໍ້ ແລະ ຮູບແບບປະໂຫຍກສະເພາະຂອງແຜນຜັງ ລ້ວນແຕ່ສຳຄັນ. ໜ້າຂໍ້ຜິດພາດທີ່ມີແບຣນຊຶ່ງມີຄຳວ່າ authentication ຢູ່ໃນເນື້ອຄວາມ ບໍ່ແມ່ນການທົດແທນຫົວຂໍ້. ການຈັດຕັ້ງແບບກຳນົດເອງກໍຕ້ອງສົ່ງ ການຕອບສະໜອງ HTTP 407 ທີ່ຄົບຖ້ວນ ເຊັ່ນກັນ ລວມທັງຕົວປິດຫົວຂໍ້ ແລະ ການກອບເນື້ອຄວາມ.

ກວດເບິ່ງການຕອບສະໜອງທີ່ມາຮອດໂປຣແກຣມລູກຄ້ານີ້

ບັນທຶກຊ່ອງສະຖານະ ແລະ ຄຳທ້າທາຍ ຫຼັງຈາກເອົາຄ່າລັບອອກແລ້ວ. ອາດມີຕົວກາງປ່ຽນແປງການຕອບສະໜອງ ຫຼື ພຣັອກຊີກຳນົດເອງໄດ້ສ້າງຄຳທ້າທາຍທີ່ບໍ່ຖືກຕ້ອງ. ປຽບທຽບຫຼັກຖານນັ້ນກັບບັນທຶກທຸລະກຳຂອງພຣັອກຊີເອງ.

ຖ້າບໍລິການສົ່ງ 405 ຫຼື ຂໍ້ຜິດພາດອື່ນແທນ, ຢ່າຕິດປ້າຍການຕອບສະໜອງແບບນັ້ນຄືນເປັນ 407 ພາຍໃນໂປຣແກຣມລູກຄ້າກຳນົດເອງ. ເຈົ້າຈະປິດບັງຄວາມລົ້ມເຫຼວທີ່ແທ້ຈິງຂອງນະໂຍບາຍວິທີການ ແລະ ຍັງຄົງບໍ່ມີການເຈລະຈາແຜນຜັງທີ່ໜ້າເຊື່ອຖື. ແກ້ໄຂພຶດຕິກຳຂອງບໍລິການ ຫຼື ໃຊ້ເສັ້ນທາງການພິສູດຕົວຕົນທີ່ໄດ້ຮັບການສະໜັບສະໜູນ ແລະ ບັນທຶກໄວ້.

ຄຳທ້າທາຍຫຼາຍອັນຍັງຕ້ອງການຕົວແຍກວິເຄາະ HTTP ທີ່ແທ້ຈິງ. ຈຸດຈ້ຳສາມາດແຍກພາລາມິເຕີ ຫຼື ຄຳທ້າທາຍ; ການແບ່ງຫົວຂໍ້ທັງໝົດຕາມຈຸດຈ້ຳຢ່າງບໍ່ລະມັດລະລະວັງ ອາດເຮັດໃຫ້ realm ທີ່ຢູ່ໃນເຄື່ອງໝາຍຄຳເວົ້າເສຍຫາຍ. ໃຊ້ການຈັດຕັ້ງການພິສູດຕົວຕົນທີ່ໂປຣແກຣມລູກຄ້າສະໜັບສະໜູນ ແທນການແທນສາຍອັກຂະຣະຕໍ່ເນື່ອງ.

ຫຼັງຈາກຄຳທ້າທາຍໃຊ້ໄດ້ແລ້ວເທົ່ານັ້ນ ການສືບສວນວ່າເປັນຫຍັງຜູ້ໃຫ້ບໍລິການຂໍ້ມູນຢືນຢັນຕົວຕົນຈຶ່ງບໍ່ສົ່ງບັນຊີກັບມາ ຈຶ່ງມີຄວາມໝາຍ.