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 ներբեռնումը:

Առնչվող հոդվածներ