Composer のプロキシ設定: REQUEST_FULLURI フラグを廃止する

Composer の古い HTTP_PROXY_REQUEST_FULLURI と関連する FULLURI の回避策は、文書化された実装ではもはや不要であり、使われてもいません。無視されるフラグは、実行中のクライアントの経路を修復できません。

POSIX シェルでコマンドラインの Composer を使う場合は、そのシェルから Composer を呼び出す前に、対応しているプロキシ変数を export してください:

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

小文字の名前が推奨されます。プロキシ自体が通常の HTTP を使う場合、どちらの値も http:// で始められます。HTTPS の宛先でも、プロキシへの接続が HTTPS である必要はありません。例の endpoint は承認済みのサービスに置き換えてください。公開された中間者を許容できる公開パッケージのダウンロードでは、HTTP プロキシ一覧から HTTP の候補を選んでください。

IDE やビルドエージェントは、自身のプロセス環境に値を持つ必要があります。あとから永続設定を変更しても、すでに実行中のプロセスは更新されません。

Composer が CLI の外で動く場合

CLI 以外の文脈での HTTP リクエストでは、Composer は http_proxy も HTTP_PROXY も使いません。代わりに CGI_HTTP_PROXY を文書化しており、リクエストヘッダーが信頼できるプロキシ設定と誤解されるのを防ぎます。シェルの解決策を Web アプリケーションにコピーせず、信頼できないリクエストからプロキシ設定を取らないでください。

失敗した操作を読む

解決できないプロキシ名、拒否された接続、407 のチャレンジ、証明書の失敗は、それぞれ別の段階を示します。古い IPv6 や証明書検証の回避策を当てるのではなく、最初の意味のあるエラーを使ってください。

Composer の HTTP ダウンロードは成功するのに Git ベースの依存関係が失敗する場合は、別の Git プロセスとその経路、そしてそのアカウントを調べてください。成功した Composer のダウンロードとは別の利用者です。