Composer প্রক্সি সেটিংস: REQUEST_FULLURI ফ্ল্যাগ বাদ দিন

Composer-এর পুরোনো HTTP_PROXY_REQUEST_FULLURI এবং সংশ্লিষ্ট FULLURI সমাধান নথিভুক্ত বাস্তবায়নে আর প্রয়োজন হয় না বা ব্যবহৃত হয় না। উপেক্ষিত ফ্ল্যাগ চলমান ক্লায়েন্টের পথ ঠিক করতে পারে না।

POSIX shell-এ কমান্ড-লাইন Composer-এর জন্য, সেই shell থেকে Composer চালানোর আগে সমর্থিত প্রক্সি চলক export করুন:

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

ছোট হাতের নাম পছন্দ করা হয়। প্রক্সি নিজেই সাধারণ HTTP ব্যবহার করলে দুটি মানই http:// দিয়ে শুরু হতে পারে; HTTPS গন্তব্যের জন্য প্রক্সিতে HTTPS সংযোগ প্রয়োজন হয় না। উদাহরণের endpoint-টি অনুমোদিত সেবা দিয়ে প্রতিস্থাপন করুন। সর্বজনীন প্যাকেজ ডাউনলোডে যেখানে সর্বজনীন মধ্যস্থতাকারী অনুমোদিত, HTTP প্রক্সি তালিকা থেকে একটি HTTP প্রার্থী বাছুন।

একটি IDE বা build agent-এর নিজের প্রক্রিয়া পরিবেশে মানগুলো প্রয়োজন। পরে স্থায়ী সেটিং পরিবর্তন করলে ইতিমধ্যে চলমান প্রক্রিয়া আপডেট হয় না।

Composer CLI-এর বাইরে চললে

CLI-এর বাইরের প্রসঙ্গে HTTP অনুরোধের জন্য Composer http_proxy বা HTTP_PROXY ব্যবহার করে না। এর বদলে এটি CGI_HTTP_PROXY নথিভুক্ত করে, যা অনুরোধ হেডারকে বিশ্বস্ত প্রক্সি কনফিগারেশন ভাবা থেকে রক্ষা করে। shell-এর সমাধান ওয়েব অ্যাপ্লিকেশনে কপি করবেন না এবং অবিশ্বস্ত অনুরোধ থেকে প্রক্সি সেটিং নেবেন না।

ব্যর্থ কাজটি পড়ুন

অমীমাংসিত প্রক্সি নাম, প্রত্যাখ্যাত সংযোগ, 407 চ্যালেঞ্জ এবং সার্টিফিকেট ব্যর্থতা ভিন্ন পর্যায় নির্দেশ করে। পুরোনো IPv6 বা সার্টিফিকেট-যাচাই সমাধান প্রয়োগ না করে প্রথম অর্থবহ ত্রুটি ব্যবহার করুন।

Composer-এর HTTP ডাউনলোড কাজ করলে কিন্তু Git-ভিত্তিক নির্ভরতা ব্যর্থ হলে, আলাদা Git প্রক্রিয়া, এর পথ ও এর অ্যাকাউন্ট পরীক্ষা করুন। এটি সফল Composer ডাউনলোড থেকে ভিন্ন ভোক্তা।