تنظیمات پروکسی Composer: پرچم‌های REQUEST_FULLURI را کنار بگذارید

راه‌حل‌های قدیمی HTTP_PROXY_REQUEST_FULLURI در Composer و راه‌حل‌های مرتبط FULLURI دیگر نه لازم‌اند و نه در پیاده‌سازی مستندشده به کار می‌روند. پرچمی که نادیده گرفته شود نمی‌تواند مسیر کلاینت در حال اجرا را درست کند.

برای Composer خط فرمان در یک پوسته POSIX، متغیرهای پروکسی پشتیبانی‌شده را پیش از فراخوانی 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 اجرا می‌شود

برای درخواست‌های HTTP در بافتی غیر از CLI، Composer از http_proxy یا HTTP_PROXY استفاده نمی‌کند. در عوض CGI_HTTP_PROXY را مستند می‌کند و از این محافظت می‌کند که سرصفحه‌های درخواست به‌اشتباه پیکربندی پروکسی مورد اعتماد تلقی شوند. راه‌حل پوسته را به یک برنامه وب کپی نکنید و تنظیمات پروکسی را از درخواست نامعتبر نگیرید.

عملیات ناموفق را بخوانید

نام پروکسی حل‌نشده، اتصال ردشده، چالش 407 و خطای گواهی به مراحل مختلف اشاره دارند. از نخستین خطای معنادار استفاده کنید، نه از راه‌حل‌های قدیمی IPv6 یا بررسی گواهی.

اگر بارگیری HTTP در Composer کار کند اما یک وابستگی مبتنی بر Git شکست بخورد، فرآیند جداگانه Git، مسیر آن و حساب آن را بررسی کنید. این مصرف‌کننده‌ای متفاوت از بارگیری موفق Composer است.