Composer പ്രോക്സി ക്രമീകരണങ്ങൾ: REQUEST_FULLURI ഫ്ലാഗുകൾ ഒഴിവാക്കുക

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 ഡൗൺലോഡിൽ നിന്ന് വ്യത്യസ്ത ഉപഭോക്താവാണ്.