إعدادات الوكيل في Composer: التخلي عن أعلام REQUEST_FULLURI

لم تعد حلول HTTP_PROXY_REQUEST_FULLURI القديمة وما يتصل بها من حلول FULLURI مطلوبة أو مستخدمة في التنفيذ الموثّق في Composer. والعلم المُهمَل لا يستطيع إصلاح مسار العميل العامل.

بالنسبة إلى Composer في سطر الأوامر داخل صدفة POSIX، صدّر متغيّرات الوكيل المدعومة قبل استدعاء Composer من تلك الصدفة:

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

يُفضَّل استخدام الأسماء بأحرف صغيرة. ويمكن أن تبدأ القيمتان بـ http:// عندما يستخدم الوكيل نفسه HTTP عاديًا؛ فالوجهة HTTPS لا تتطلب اتصال HTTPS بالوكيل. استبدل نقطة النهاية المذكورة في المثال بالخدمة المعتمدة. ولتنزيلات الحزم العامة حيث يُسمح بوسيط عام، اختر مرشحًا من نوع HTTP من قائمة وكلاء HTTP.

يحتاج محرّر IDE أو وكيل البناء إلى القيم في بيئة عمليته الخاصة. وتغيير إعداد دائم بعد ذلك لا يحدّث عملية تعمل بالفعل.

عندما يعمل Composer خارج سطر الأوامر

بالنسبة إلى طلبات HTTP في سياق غير سطر الأوامر، لا يستخدم Composer http_proxy ولا HTTP_PROXY. بل يوثّق CGI_HTTP_PROXY بدلًا من ذلك، حمايةً من أن تُفهَم ترويسات الطلب على أنها إعدادات وكيل موثوقة. لا تنسخ حل الصدفة إلى تطبيق ويب ولا تأخذ إعدادات الوكيل من طلب غير موثوق.

اقرأ العملية الفاشلة

اسم وكيل غير قابل للحل، أو اتصال مرفوض، أو تحدّي 407، أو فشل شهادة: كلها تشير إلى مراحل مختلفة. استخدم أول خطأ ذي معنى بدلًا من تطبيق حلول قديمة خاصة بـ IPv6 أو التحقق من الشهادات.

إذا نجح تنزيل HTTP في Composer وفشل اعتماد قائم على Git، فافحص عملية Git المنفصلة ومسارها وحسابها. فذلك مستهلك مختلف عن تنزيل Composer الناجح.