Прокси настройки на Composer: откажете се от флаговете REQUEST_FULLURI

Старите HTTP_PROXY_REQUEST_FULLURI на Composer и свързаните с тях решения FULLURI вече не са нужни и не се използват в документираната реализация. Игнориран флаг не може да поправи маршрута на работещия клиент.

За Composer от командния ред в POSIX shell експортирайте поддържаните прокси променливи, преди да извикате Composer от този shell:

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

Предпочитат се имена с малки букви. И двете стойности могат да започват с http://, когато самият прокси използва обикновен HTTP; HTTPS дестинация не изисква HTTPS връзка към проксито. Заменете примерния endpoint с одобрената услуга. За публични изтегляния на пакети, където е разрешен публичен посредник, изберете HTTP кандидат от списъка с HTTP проксита.

IDE или агент за изграждане се нуждае от стойностите в собствената си среда на процеса. Промяната на постоянна настройка по-късно не обновява вече работещ процес.

Когато Composer работи извън CLI

За HTTP заявки извън CLI контекст Composer не използва http_proxy или HTTP_PROXY. Вместо това документира CGI_HTTP_PROXY, което предпазва от това заглавките на заявката да бъдат взети за доверена прокси конфигурация. Не копирайте решението за shell в уеб приложение и не взимайте прокси настройки от недоверена заявка.

Прочетете неуспешната операция

Неразрешено име на прокси, отказана връзка, 407 предизвикателство и грешка със сертификат сочат към различни етапи. Използвайте първата смислена грешка, вместо да прилагате стари решения за IPv6 или проверка на сертификати.

Ако HTTP изтеглянето на Composer работи, а зависимост през Git се проваля, прегледайте отделния Git процес, маршрута му и неговия акаунт. Това е различен потребител от успешното изтегляне на Composer.