HTTP_PROXY_REQUEST_FULLURI ແບບເກົ່າຂອງ Composer ແລະ ວິທີແກ້ໄຂ FULLURI ທີ່ກ່ຽວຂ້ອງ ບໍ່ຈຳເປັນ ແລະ ບໍ່ຖືກໃຊ້ໃນການຈັດຕັ້ງທີ່ບັນທຶກໄວ້ອີກຕໍ່ໄປ. flag ທີ່ຖືກລະເລີຍບໍ່ສາມາດແກ້ເສັ້ນທາງຂອງ client ທີ່ກຳລັງແລ່ນຢູ່ໄດ້.

ສຳລັບ Composer ແບບ command line ໃນ shell POSIX, ໃຫ້ export ໂຕແປ proxy ທີ່ຮອງຮັບ ກ່ອນທີ່ຈະເອີ້ນ Composer ຈາກ shell ນັ້ນ:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

ຊື່ທີ່ເປັນຕົວພິມນ້ອຍໄດ້ຮັບການມັກ. ທັງສອງຄ່າສາມາດເລີ່ມດ້ວຍ http:// ເມື່ອ proxy ເອງໃຊ້ HTTP ທຳມະດາ; ປາຍທາງ HTTPS ບໍ່ຕ້ອງການການເຊື່ອມຕໍ່ HTTPS ຫາ proxy. ໃຫ້ປ່ຽນ endpoint ຕົວຢ່າງດ້ວຍບໍລິການທີ່ໄດ້ຮັບອະນຸມັດ. ສຳລັບການດາວໂຫຼດແພັກເກດສາທາລະນະ ທີ່ອະນຸຍາດໃຫ້ໃຊ້ຕົວກາງສາທາລະນະ, ໃຫ້ເລືອກຜູ້ສະໝັກ HTTP ຈາກລາຍຊື່ proxy HTTP.

IDE ຫຼື build agent ຕ້ອງການຄ່າເຫຼົ່ານີ້ໃນສະພາບແວດລ້ອມຂະບວນການຂອງຕົນເອງ. ການປ່ຽນການຕັ້ງຄ່າແບບຖາວອນພາຍຫຼັງ ບໍ່ໄດ້ອັບເດດຂະບວນການທີ່ກຳລັງແລ່ນຢູ່ແລ້ວ.

ເມື່ອ Composer ແລ່ນຢູ່ນອກ CLI

ສຳລັບຄຳຮ້ອງ HTTP ໃນບໍລິບົດທີ່ບໍ່ແມ່ນ CLI, Composer ບໍ່ໄດ້ໃຊ້ http_proxy ຫຼື HTTP_PROXY. ແທນນັ້ນມັນບັນທຶກ CGI_HTTP_PROXY ເຊິ່ງປ້ອງກັນບໍ່ໃຫ້ຫົວຄຳຮ້ອງຖືກເຂົ້າໃຈຜິດວ່າເປັນການຕັ້ງຄ່າ proxy ທີ່ໜ້າເຊື່ອຖື. ຢ່າຄັດລອກວິທີແກ້ໄຂຂອງ shell ໄປໃສ່ແອັບພລິເຄຊັນເວັບ ແລະ ຢ່າເອົາການຕັ້ງຄ່າ proxy ຈາກຄຳຮ້ອງທີ່ບໍ່ໜ້າເຊື່ອຖື.

ອ່ານການດຳເນີນການທີ່ລົ້ມເຫຼວ

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

ຖ້າການດາວໂຫຼດ HTTP ຂອງ Composer ເຮັດວຽກ ແຕ່ການອີງໃສ່ Git ລົ້ມເຫຼວ, ໃຫ້ກວດຂະບວນການ Git ແຍກຕ່າງຫາກ, ເສັ້ນທາງຂອງມັນ ແລະ ບັນຊີຂອງມັນ. ນັ້ນເປັນຜູ້ໃຊ້ທີ່ແຕກຕ່າງຈາກການດາວໂຫຼດ Composer ທີ່ສຳເລັດ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ