Les anciens HTTP_PROXY_REQUEST_FULLURI de Composer et les contournements FULLURI associés ne sont plus nécessaires ni utilisés dans l'implémentation documentée. Un indicateur ignoré ne peut pas réparer la route du client en cours d'exécution.

Pour Composer en ligne de commande dans un shell POSIX, exportez les variables de proxy prises en charge avant d'invoquer Composer depuis ce shell :

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

Les noms en minuscules sont préférés. Les deux valeurs peuvent commencer par http:// lorsque le proxy lui-même utilise du HTTP ordinaire ; une destination HTTPS n'exige pas de connexion HTTPS vers le proxy. Remplacez l'endpoint d'exemple par le service approuvé. Pour les téléchargements publics de paquets où un intermédiaire public est autorisé, choisissez un candidat HTTP dans la liste de proxys HTTP.

Un IDE ou un agent de build a besoin des valeurs dans son propre environnement de processus. Modifier ensuite un réglage permanent ne met pas à jour un processus déjà en cours d'exécution.

Lorsque Composer s'exécute hors de la CLI

Pour les requêtes HTTP dans un contexte non CLI, Composer n'utilise pas http_proxy ni HTTP_PROXY. Il documente plutôt CGI_HTTP_PROXY, ce qui évite que les en-têtes de requête soient pris pour une configuration de proxy de confiance. Ne copiez pas la solution du shell dans une application web et ne prenez pas de paramètres de proxy depuis une requête non fiable.

Lire l'opération qui a échoué

Un nom de proxy non résolu, une connexion refusée, un défi 407 et une erreur de certificat désignent des étapes différentes. Utilisez la première erreur significative plutôt que d'appliquer d'anciens contournements IPv6 ou de vérification de certificat.

Si le téléchargement HTTP de Composer fonctionne mais qu'une dépendance via Git échoue, examinez le processus Git séparé, sa route et son compte. C'est un consommateur différent du téléchargement Composer réussi.

Articles similaires