Proxyinställningar i Composer: avveckla REQUEST_FULLURI-flaggorna

Composers gamla HTTP_PROXY_REQUEST_FULLURI och tillhörande FULLURI-lösningar behövs inte längre och används inte i den dokumenterade implementeringen. En ignorerad flagga kan inte reparera den körande klientens rutt.

För Composer på kommandoraden i ett POSIX-skal, exportera de proxyvariabler som stöds innan du anropar Composer från det skalet:

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

Namn med små bokstäver föredras. Båda värdena kan börja med http:// när proxyn själv använder vanlig HTTP; ett HTTPS-mål kräver ingen HTTPS-anslutning till proxyn. Ersätt exempel-endpointen med den godkända tjänsten. För offentliga paketnedladdningar där en offentlig mellanhand är tillåten, välj en HTTP-kandidat från HTTP-proxylistan.

En IDE eller byggagent behöver värdena i sin egen processmiljö. Att ändra en permanent inställning efteråt uppdaterar inte en process som redan körs.

När Composer körs utanför CLI

För HTTP-förfrågningar i en icke-CLI-kontext använder Composer inte http_proxy eller HTTP_PROXY. I stället dokumenterar den CGI_HTTP_PROXY, vilket skyddar mot att förfrågningshuvuden tas för betrodd proxykonfiguration. Kopiera inte skal-lösningen till en webbapplikation och hämta inte proxyinställningar från en obetrodd förfrågan.

Läs den misslyckade åtgärden

Ett olöst proxynamn, en nekad anslutning, en 407-utmaning och ett certifikatfel pekar på olika steg. Använd det första meningsfulla felet i stället för att tillämpa gamla IPv6- eller certifikatverifieringslösningar.

Om Composers HTTP-nedladdning fungerar men ett Git-baserat beroende misslyckas, granska den separata Git-processen, dess rutt och dess konto. Det är en annan konsument än den lyckade Composer-nedladdningen.