Composer-ի պրոքսի կարգավորումներ. հրաժարվեք REQUEST_FULLURI դրոշակներից
Ընթացիկ 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 ներբեռնումը: