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 किंवा build एजंटला मूल्ये त्याच्या स्वतःच्या प्रक्रिया पर्यावरणात हवी असतात. नंतर कायमचे सेटिंग बदलल्याने आधीच चालू असलेली प्रक्रिया अद्ययावत होत नाही.

जेव्हा Composer CLI बाहेर चालतो

CLI नसलेल्या संदर्भातील HTTP विनंत्यांसाठी Composer http_proxy किंवा HTTP_PROXY वापरत नाही. त्याऐवजी तो CGI_HTTP_PROXY चे दस्तऐवजीकरण करतो, ज्यामुळे विनंती हेडर विश्वासार्ह प्रॉक्सी कॉन्फिगरेशन म्हणून समजले जाण्यापासून संरक्षण होते. शेलचा उपाय वेब अनुप्रयोगात कॉपी करू नका आणि अविश्वासार्ह विनंतीतून प्रॉक्सी सेटिंग घेऊ नका.

अयशस्वी क्रिया वाचा

न सुटलेले प्रॉक्सी नाव, नाकारलेले कनेक्शन, 407 आव्हान आणि प्रमाणपत्र अपयश वेगवेगळ्या टप्प्यांकडे निर्देश करतात. जुने IPv6 किंवा प्रमाणपत्र-पडताळणी उपाय लागू करण्याऐवजी पहिली अर्थपूर्ण त्रुटी वापरा.

जर Composer चे HTTP डाउनलोड काम करते पण Git-आधारित अवलंबन अयशस्वी होते, तर वेगळी Git प्रक्रिया, तिचा मार्ग आणि तिचे खाते तपासा. तो यशस्वी Composer डाउनलोडपेक्षा वेगळा वापरकर्ता आहे.

संबंधित लेख