Налаштування проксі в Composer: відмовтеся від прапорців REQUEST_FULLURI

Поточний Composer документує змінні середовища проксі й більше не використовує старі обхідні рішення REQUEST_FULLURI, що трапляються в багатьох відповідях.

Старі HTTP_PROXY_REQUEST_FULLURI у Composer і пов'язані обхідні рішення FULLURI більше не потрібні й не використовуються в документованій реалізації. Проігнорований прапорець не може виправити маршрут працюючого клієнта.

Для Composer у командному рядку в оболонці POSIX експортуйте підтримувані змінні проксі перед викликом Composer із цієї оболонки:

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

Перевага надається назвам у нижньому регістрі. Обидва значення можуть починатися з http://, коли сам проксі використовує звичайний HTTP; призначення HTTPS не потребує HTTPS-з'єднання з проксі. Замініть приклад endpoint на схвалений сервіс. Для публічних завантажень пакетів, де дозволено публічного посередника, виберіть HTTP-кандидата зі списку HTTP-проксі.

IDE або агенту збірки потрібні значення в його власному середовищі процесу. Зміна постійного налаштування пізніше не оновлює вже запущений процес.

Коли Composer працює поза CLI

Для HTTP-запитів поза контекстом CLI Composer не використовує http_proxy або HTTP_PROXY. Натомість він документує CGI_HTTP_PROXY, що захищає від сприйняття заголовків запиту як довіреної конфігурації проксі. Не копіюйте рішення для оболонки у вебзастосунок і не беріть налаштування проксі з недовіреного запиту.

Прочитайте невдалу операцію

Невирішене ім'я проксі, відхилене з'єднання, запит 407 і помилка сертифіката вказують на різні етапи. Використовуйте першу значущу помилку, а не застосовуйте старі обхідні рішення IPv6 чи перевірки сертифікатів.

Якщо HTTP-завантаження в Composer працює, а залежність через Git не проходить, перегляньте окремий процес Git, його маршрут і його обліковий запис. Це інший споживач, ніж успішне завантаження Composer.

Схожі статті