Impostazioni proxy di Composer: ritirare i flag REQUEST_FULLURI

I vecchi HTTP_PROXY_REQUEST_FULLURI di Composer e le soluzioni FULLURI correlate non sono più necessari né usati nell'implementazione documentata. Un flag ignorato non può riparare il percorso del client in esecuzione.

Per Composer da riga di comando in una shell POSIX, esporta le variabili proxy supportate prima di invocare Composer da quella shell:

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

Si preferiscono i nomi in minuscolo. Entrambi i valori possono iniziare con http:// quando il proxy stesso usa HTTP normale; una destinazione HTTPS non richiede una connessione HTTPS al proxy. Sostituisci l'endpoint di esempio con il servizio approvato. Per i download pubblici di pacchetti in cui è consentito un intermediario pubblico, scegli un candidato HTTP dall'elenco di proxy HTTP.

Un IDE o un agente di build ha bisogno dei valori nel proprio ambiente di processo. Modificare in seguito un'impostazione permanente non aggiorna un processo già in esecuzione.

Quando Composer viene eseguito fuori dalla CLI

Per le richieste HTTP in un contesto non CLI, Composer non usa http_proxy né HTTP_PROXY. Documenta invece CGI_HTTP_PROXY, evitando che le intestazioni della richiesta siano scambiate per una configurazione proxy attendibile. Non copiare la soluzione della shell in un'applicazione web e non prendere impostazioni proxy da una richiesta non attendibile.

Leggi l'operazione non riuscita

Un nome proxy non risolto, una connessione rifiutata, una richiesta di autenticazione 407 e un errore di certificato indicano fasi diverse. Usa il primo errore significativo invece di applicare vecchie soluzioni IPv6 o di verifica dei certificati.

Se il download HTTP di Composer funziona ma una dipendenza basata su Git fallisce, esamina il processo Git separato, il suo percorso e il suo account. È un consumatore diverso dal download Composer riuscito.