Старите 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 или build агент му требаат вредностите во сопствената околина на процесот. Промената на постојана поставка подоцна не го ажурира веќе активниот процес.

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

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

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

Неразрешено име на прокси, одбиена врска, предизвик 407 и грешка со сертификат укажуваат на различни фази. Користете ја првата значајна грешка наместо да применувате стари решенија за IPv6 или проверка на сертификати.

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

Поврзани статии