Setări proxy în Composer: renunțați la indicatorii REQUEST_FULLURI

Vechii HTTP_PROXY_REQUEST_FULLURI din Composer și soluțiile FULLURI asociate nu mai sunt necesare și nu sunt folosite în implementarea documentată. Un indicator ignorat nu poate repara ruta clientului aflat în execuție.

Pentru Composer din linia de comandă într-un shell POSIX, exportați variabilele proxy acceptate înainte de a apela Composer din acel shell:

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

Sunt preferate numele cu litere mici. Ambele valori pot începe cu http:// când proxy-ul însuși folosește HTTP obișnuit; o destinație HTTPS nu necesită o conexiune HTTPS la proxy. Înlocuiți endpoint-ul exemplu cu serviciul aprobat. Pentru descărcările publice de pachete unde este permis un intermediar public, alegeți un candidat HTTP din lista de proxy-uri HTTP.

Un IDE sau un agent de build are nevoie de valori în propriul mediu de proces. Modificarea ulterioară a unei setări permanente nu actualizează un proces deja pornit.

Când Composer rulează în afara CLI

Pentru cererile HTTP într-un context non-CLI, Composer nu folosește http_proxy sau HTTP_PROXY. În schimb documentează CGI_HTTP_PROXY, ceea ce împiedică interpretarea antetelor cererii drept configurație de proxy de încredere. Nu copiați soluția pentru shell într-o aplicație web și nu preluați setări de proxy dintr-o cerere neîncrezută.

Citiți operația eșuată

Un nume de proxy nerezolvat, o conexiune refuzată, o provocare 407 și o eroare de certificat indică etape diferite. Folosiți prima eroare semnificativă în loc să aplicați soluții vechi pentru IPv6 sau verificarea certificatelor.

Dacă descărcarea HTTP a Composer funcționează, dar o dependență bazată pe Git eșuează, examinați procesul Git separat, ruta acestuia și contul său. Acesta este un consumator diferit față de descărcarea reușită a Composer.