La malnovaj HTTP_PROXY_REQUEST_FULLURI de Composer kaj rilataj FULLURI-solvoj ne plu necesas nek estas uzataj en la dokumentita efektivigo. Ignorita flago ne povas ripari la vojon de la kuranta kliento.

Por komandlinia Composer en POSIX-ŝelo, eksportu la subtenatajn proksajn variablojn antaŭ ol voki Composer el tiu ŝelo:

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

Minusklaj nomoj estas preferataj. Ambaŭ valoroj povas komenciĝi per http:// kiam la prokso mem uzas ordinaran HTTP; HTTPS-celo ne postulas HTTPS-konekton al la prokso. Anstataŭigu la ekzemplan endpoint per la aprobita servo. Por publikaj pakaĵelŝutoj kie publika peranto estas permesata, elektu HTTP-kandidaton el la HTTP-proksa listo.

IDE aŭ konstru-aganto bezonas la valorojn en sia propra proceza medio. Ŝanĝi daŭran agordon poste ne ĝisdatigas jam kurantan procezon.

Kiam Composer funkcias ekster la CLI

Por HTTP-petoj en ne-CLI-kunteksto, Composer ne uzas http_proxy nek HTTP_PROXY. Anstataŭe ĝi dokumentas CGI_HTTP_PROXY, protektante kontraŭ tio, ke petaj kaplinioj estu konsiderataj fidinda proksa agordo. Ne kopiu la ŝelan solvon en retan aplikaĵon kaj ne prenu proksajn agordojn el nefidinda peto.

Legu la malsukcesan operacion

Nesolvita proksa nomo, rifuzita konekto, 407-defio kaj atestila fiasko montras al malsamaj etapoj. Uzu la unuan signifan eraron anstataŭ apliki malnovajn IPv6- aŭ atestil-kontrolajn solvojn.

Se la HTTP-elŝuto de Composer funkcias sed Git-bazita dependaĵo malsukcesas, kontrolu la apartan Git-procezon, ĝian vojon kaj ĝian konton. Tiu estas alia konsumanto ol la sukcesa Composer-elŝuto.

Rilataj artikoloj