Composer-ის პროქსის პარამეტრები: უარი თქვით REQUEST_FULLURI დროშებზე

Composer-ის ძველი HTTP_PROXY_REQUEST_FULLURI და მასთან დაკავშირებული FULLURI გადაწყვეტები დოკუმენტირებულ იმპლემენტაციაში აღარ არის საჭირო და არ გამოიყენება. უგულებელყოფილი დროშა ვერ შეაკეთებს მომუშავე კლიენტის მარშრუტს.

POSIX shell-ში ბრძანების ხაზის Composer-ისთვის, ექსპორტეთ მხარდაჭერილი პროქსის ცვლადები, სანამ ამ shell-იდან Composer-ს გამოიძახებთ:

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

უპირატესობა ენიჭება პატარა ასოებიან სახელებს. ორივე მნიშვნელობა შეიძლება იწყებოდეს http://-ით, როცა თავად პროქსი იყენებს ჩვეულებრივ HTTP-ს; HTTPS დანიშნულება არ მოითხოვს HTTPS კავშირს პროქსისთან. შეცვალეთ მაგალითის endpoint დამტკიცებული სერვისით. საჯარო პაკეტების ჩამოტვირთვისას, სადაც საჯარო შუამავალი დაშვებულია, აირჩიეთ HTTP კანდიდატი HTTP პროქსების სიიდან.

IDE-ს ან build აგენტს მნიშვნელობები სჭირდება საკუთარ პროცესის გარემოში. მუდმივი პარამეტრის მოგვიანებით შეცვლა არ განაახლებს უკვე მომუშავე პროცესს.

როცა Composer CLI-ს გარეთ მუშაობს

CLI-ს გარეთ კონტექსტში HTTP მოთხოვნებისთვის Composer არ იყენებს http_proxy-ს ან HTTP_PROXY-ს. სამაგიეროდ ის აღწერს CGI_HTTP_PROXY-ს, რაც იცავს მოთხოვნის თავსართების სანდო პროქსის კონფიგურაციად მიჩნევისგან. ნუ დააკოპირებთ shell-ის გადაწყვეტას ვებ აპლიკაციაში და ნუ აიღებთ პროქსის პარამეტრებს არასანდო მოთხოვნიდან.

წაიკითხეთ წარუმატებელი ოპერაცია

გადაუჭრელი პროქსის სახელი, უარყოფილი კავშირი, 407 გამოწვევა და სერტიფიკატის შეცდომა სხვადასხვა ეტაპს მიუთითებს. გამოიყენეთ პირველი მნიშვნელოვანი შეცდომა, ნაცვლად ძველი IPv6 ან სერტიფიკატის შემოწმების გადაწყვეტების გამოყენებისა.

თუ Composer-ის HTTP ჩამოტვირთვა მუშაობს, მაგრამ Git-ზე დაფუძნებული დამოკიდებულება ვერ ხერხდება, შეამოწმეთ ცალკე Git პროცესი, მისი მარშრუტი და მისი ანგარიში. ეს სხვა მომხმარებელია, ვიდრე წარმატებული Composer ჩამოტვირთვა.