Налады проксі Composer: адмовіцеся ад сцягоў REQUEST_FULLURI

Старыя HTTP_PROXY_REQUEST_FULLURI Composer і звязаныя з імі абыходы FULLURI больш не патрабуюцца і не выкарыстоўваюцца ў дакументаванай рэалізацыі. Праігнараваны сцяг не можа выправіць маршрут працуючага кліента.

Для Composer у камандным радку ў POSIX-абалонцы экспартуйце падтрымліваемыя зменныя проксі перад выклікам Composer з гэтай абалонкі:

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, што абараняе ад прыняцця загалоўкаў запыту за давераную канфігурацыю проксі. Не пераносьце рашэнне для абалонкі ў вэб-праграму і не бярыце налады проксі з недаверанага запыту.

Чытайце няўдалую аперацыю

Нявырашанае імя проксі, адхіленае злучэнне, выклік 407 і памылка сертыфіката ўказваюць на розныя этапы. Выкарыстоўвайце першую значную памылку, а не ўжывайце старыя абыходы IPv6 ці праверкі сертыфікатаў.

Калі HTTP-спампоўка Composer працуе, але залежнасць праз Git не, агледзьце асобны працэс Git, яго маршрут і яго ўліковы запіс. Гэта іншы спажывец, чым паспяховая спампоўка Composer.