Proxy-instellingen van Composer: de REQUEST_FULLURI-vlaggen laten vallen

De oude HTTP_PROXY_REQUEST_FULLURI van Composer en de bijbehorende FULLURI-oplossingen zijn in de gedocumenteerde implementatie niet meer nodig en worden niet gebruikt. Een genegeerde vlag kan de route van de draaiende client niet herstellen.

Exporteer voor Composer op de opdrachtregel in een POSIX-shell de ondersteunde proxyvariabelen voordat je Composer vanuit die shell aanroept:

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

Namen met kleine letters hebben de voorkeur. Beide waarden mogen met http:// beginnen wanneer de proxy zelf gewone HTTP gebruikt; een HTTPS-bestemming vereist geen HTTPS-verbinding met de proxy. Vervang de voorbeeld-endpoint door de goedgekeurde dienst. Kies voor openbare pakketdownloads waar een openbare tussenpartij is toegestaan een HTTP-kandidaat uit de HTTP-proxylijst.

Een IDE of build-agent heeft de waarden in zijn eigen procesomgeving nodig. Een permanente instelling later wijzigen werkt een al draaiend proces niet bij.

Wanneer Composer buiten de CLI draait

Voor HTTP-verzoeken in een niet-CLI-context gebruikt Composer niet http_proxy of HTTP_PROXY. In plaats daarvan documenteert het CGI_HTTP_PROXY, wat voorkomt dat verzoekheaders worden aangezien voor vertrouwde proxyconfiguratie. Kopieer de shell-oplossing niet naar een webapplicatie en neem geen proxyinstellingen over uit een niet-vertrouwd verzoek.

Lees de mislukte bewerking

Een niet-opgeloste proxynaam, een geweigerde verbinding, een 407-uitdaging en een certificaatfout wijzen op verschillende fasen. Gebruik de eerste betekenisvolle fout in plaats van oude IPv6- of certificaatverificatie-oplossingen toe te passen.

Als de HTTP-download van Composer werkt maar een op Git gebaseerde afhankelijkheid mislukt, onderzoek dan het afzonderlijke Git-proces, de route ervan en het account. Dat is een andere gebruiker dan de geslaagde Composer-download.